date:20190527

Formats are read-only internal memory structures, so make them const.

Signed-off-by: Alexandre Courbot 
---
 .../platform/mtk-vcodec/mtk_vcodec_dec.c  | 19 ++-
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  2 +-
 .../platform/mtk-vcodec/mtk_vcodec_enc.c  | 19 ++-
 3 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 851903867bc9..2175883e22d4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -32,7 +32,7 @@
 #define DFT_CFG_WIDTH  MTK_VDEC_MIN_W
 #define DFT_CFG_HEIGHT MTK_VDEC_MIN_H
 
-static struct mtk_video_fmt mtk_video_formats[] = {
+static const struct mtk_video_fmt mtk_video_formats[] = {
{
.fourcc = V4L2_PIX_FMT_H264,
.type = MTK_FMT_DEC,
@@ -76,9 +76,9 @@ static const struct mtk_codec_framesizes 
mtk_vdec_framesizes[] = {
 #define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_vdec_framesizes)
 #define NUM_FORMATS ARRAY_SIZE(mtk_video_formats)
 
-static struct mtk_video_fmt *mtk_vdec_find_format(struct v4l2_format *f)
+static const struct mtk_video_fmt *mtk_vdec_find_format(struct v4l2_format *f)
 {
-   struct mtk_video_fmt *fmt;
+   const struct mtk_video_fmt *fmt;
unsigned int k;
 
for (k = 0; k < NUM_FORMATS; k++) {
@@ -279,7 +279,7 @@ static void mtk_vdec_flush_decoder(struct mtk_vcodec_ctx 
*ctx)
 static void mtk_vdec_update_fmt(struct mtk_vcodec_ctx *ctx,
unsigned int pixelformat)
 {
-   struct mtk_video_fmt *fmt;
+   const struct mtk_video_fmt *fmt;
struct mtk_q_data *dst_q_data;
unsigned int k;
 
@@ -652,7 +652,8 @@ static int vidioc_vdec_subscribe_evt(struct v4l2_fh *fh,
}
 }
 
-static int vidioc_try_fmt(struct v4l2_format *f, struct mtk_video_fmt *fmt)
+static int vidioc_try_fmt(struct v4l2_format *f,
+ const struct mtk_video_fmt *fmt)
 {
struct v4l2_pix_format_mplane *pix_fmt_mp = >fmt.pix_mp;
int i;
@@ -725,7 +726,7 @@ static int vidioc_try_fmt(struct v4l2_format *f, struct 
mtk_video_fmt *fmt)
 static int vidioc_try_fmt_vid_cap_mplane(struct file *file, void *priv,
struct v4l2_format *f)
 {
-   struct mtk_video_fmt *fmt;
+   const struct mtk_video_fmt *fmt;
 
fmt = mtk_vdec_find_format(f);
if (!fmt) {
@@ -740,7 +741,7 @@ static int vidioc_try_fmt_vid_out_mplane(struct file *file, 
void *priv,
struct v4l2_format *f)
 {
struct v4l2_pix_format_mplane *pix_fmt_mp = >fmt.pix_mp;
-   struct mtk_video_fmt *fmt;
+   const struct mtk_video_fmt *fmt;
 
fmt = mtk_vdec_find_format(f);
if (!fmt) {
@@ -834,7 +835,7 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
struct v4l2_pix_format_mplane *pix_mp;
struct mtk_q_data *q_data;
int ret = 0;
-   struct mtk_video_fmt *fmt;
+   const struct mtk_video_fmt *fmt;
 
mtk_v4l2_debug(3, "[%d]", ctx->id);
 
@@ -933,7 +934,7 @@ static int vidioc_enum_framesizes(struct file *file, void 
*priv,
 
 static int vidioc_enum_fmt(struct v4l2_fmtdesc *f, bool output_queue)
 {
-   struct mtk_video_fmt *fmt;
+   const struct mtk_video_fmt *fmt;
int i, j = 0;
 
for (i = 0; i < NUM_FORMATS; i++) {
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 5da42f555b52..109c7578a8b2 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -137,7 +137,7 @@ struct mtk_q_data {
enum v4l2_field field;
unsigned intbytesperline[MTK_VCODEC_MAX_PLANES];
unsigned intsizeimage[MTK_VCODEC_MAX_PLANES];
-   struct mtk_video_fmt*fmt;
+   const struct mtk_video_fmt  *fmt;
 };
 
 /**
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 50351adafc47..2d5a61c06287 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -37,7 +37,7 @@
 
 static void mtk_venc_worker(struct work_struct *work);
 
-static struct mtk_video_fmt mtk_video_formats[] = {
+static const struct mtk_video_fmt mtk_video_formats[] = {
{
.fourcc = V4L2_PIX_FMT_NV12M,
.type = MTK_FMT_FRAME,
@@ -166,7 +166,7 @@ static const struct v4l2_ctrl_ops mtk_vcodec_enc_ctrl_ops = 
{
 
 static int vidioc_enum_fmt(struct v4l2_fmtdesc *f, bool output_queue)
 {
-   struct mtk_video_fmt *fmt;
+   const struct mtk_video_fmt *fmt;
int i, j = 0;
 
for (i = 0; i < NUM_FORMATS; ++i) {
@@ -274,9 +274,9 @@ static struct mtk_q_data *mtk_venc_get_q_data(struct 
mtk_vcodec_ctx *ctx,

[RFCv1 08/12] media: mtk-vcodec: add SCP firmware ops

From: Yunfei Dong 

Add support for communicating with the SCP firmware, which will be used
by MT8183.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]
---
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  |  3 ++
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |  3 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 51 +++
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.h |  2 +
 4 files changed, 59 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 2328bb9580be..ffa6f3d0869d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -234,6 +234,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu",
  _phandle)) {
fw_type = VPU;
+   } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
+_phandle)) {
+   fw_type = SCP;
} else {
mtk_v4l2_err("Could not get vdec IPI device");
return -ENODEV;
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 598d4bb86e35..da680087b655 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -242,6 +242,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu",
  _phandle)) {
fw_type = VPU;
+   } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
+_phandle)) {
+   fw_type = SCP;
} else {
mtk_v4l2_err("Could not get vdec IPI device");
return -ENODEV;
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
index 49dbd623b448..97282b35bcc2 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
@@ -63,6 +63,48 @@ static const struct mtk_vcodec_fw_ops mtk_vcodec_vpu_msg = {
.ipi_send = mtk_vcodec_vpu_ipi_send,
 };
 
+static int mtk_vcodec_scp_load_firmware(struct mtk_vcodec_fw *fw)
+{
+   return rproc_boot(fw->rproc);
+}
+
+static unsigned int mtk_vcodec_scp_get_vdec_capa(struct mtk_vcodec_fw *fw)
+{
+   return scp_get_vdec_hw_capa(fw->pdev);
+}
+
+static unsigned int mtk_vcodec_scp_get_venc_capa(struct mtk_vcodec_fw *fw)
+{
+   return scp_get_venc_hw_capa(fw->pdev);
+}
+
+static void *mtk_vcodec_vpu_scp_dm_addr(struct mtk_vcodec_fw *fw,
+   u32 dtcm_dmem_addr)
+{
+   return scp_mapping_dm_addr(fw->pdev, dtcm_dmem_addr);
+}
+
+static int mtk_vcodec_scp_set_ipi_register(struct mtk_vcodec_fw *fw, int id,
+   mtk_vcodec_ipi_handler handler, const char *name, void *priv)
+{
+   return scp_ipi_register(fw->pdev, id, handler, priv);
+}
+
+static int mtk_vcodec_scp_ipi_send(struct mtk_vcodec_fw *fw, int id, void *buf,
+   unsigned int len, unsigned int wait)
+{
+   return scp_ipi_send(fw->pdev, id, buf, len, wait);
+}
+
+static const struct mtk_vcodec_fw_ops mtk_vcodec_rproc_msg = {
+   .load_firmware = mtk_vcodec_scp_load_firmware,
+   .get_vdec_capa = mtk_vcodec_scp_get_vdec_capa,
+   .get_venc_capa = mtk_vcodec_scp_get_venc_capa,
+   .map_dm_addr = mtk_vcodec_vpu_scp_dm_addr,
+   .ipi_register = mtk_vcodec_scp_set_ipi_register,
+   .ipi_send = mtk_vcodec_scp_ipi_send,
+};
+
 static void mtk_vcodec_reset_handler(void *priv)
 {
struct mtk_vcodec_dev *dev = priv;
@@ -96,6 +138,15 @@ struct mtk_vcodec_fw *mtk_vcodec_fw_select(struct 
mtk_vcodec_dev *dev,
vpu_wdt_reg_handler(fw_pdev, mtk_vcodec_reset_handler,
dev, rst_id);
break;
+   case SCP:
+   ops = _vcodec_rproc_msg;
+   fw_pdev = scp_get_pdev(dev->plat_dev);
+   rproc = rproc_get_by_phandle(rproc_phandle);
+   if (!rproc) {
+   mtk_v4l2_err("could not get vdec rproc handle");
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+   break;
default:
mtk_v4l2_err("invalid vcodec fw type");
return ERR_PTR(-EINVAL);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h
index a6edb3858e6e..c2c22c7ce05f 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h
@@ -6,11 +6,13 @@
 #include

Re: [PATCH v6 0/5] prerequisites for device reserved local mem rework

2019-05-27 Thread Christoph Hellwig

On Thu, May 23, 2019 at 09:07:55AM +0200, Greg KH wrote:
> I have no objection for you just taking this whole series as-is, no need
> to worry about merge conflicts with the USB tree, I doubt anything will
> be touching this area of code anytime soon.
> 
> So if you want to take it now, feel free to add:
> 
> Signed-off-by: Greg Kroah-Hartman 

Given that I'll pull it in, shouldn't this be a Reviewed-by or Acked-by?

[RFCv1 12/12] media: mtk-vcodec: enable MT8183 decoder

From: Yunfei Dong 

Now that all the supporting blocks are present, enable decoder for
MT8183.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]

Change-Id: I5696b186fae16f12b97745247331732beb1192e2
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 8be0c04f7e81..60dd312500a4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -401,6 +401,10 @@ static const struct of_device_id mtk_vcodec_match[] = {
.compatible = "mediatek,mt8173-vcodec-dec",
.data = _frame_8173_pdata,
},
+   {
+   .compatible = "mediatek,mt8183-vcodec-dec",
+   .data = _req_8183_pdata,
+   },
{},
 };
 
-- 
2.22.0.rc1.257.g3120a18244-goog

[RFCv1 06/12] media: mtk-vcodec: move stateful ops into their own file

From: Yunfei Dong 

We are planning to add support for stateless formats to this driver.
Part of the driver will be shared between stateful and stateless
formats, but a few ops need to be specialized for both. Extract the
stateful part of the driver and move it into its own file, accessible
through ops that the common driver parts can call.

This patch only moves code around and introduces a set of abstractions ;
behavior or the driver should not be changed in any way.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]
---
 drivers/media/platform/mtk-vcodec/Makefile|   1 +
 .../platform/mtk-vcodec/mtk_vcodec_dec.c  | 694 ++
 .../platform/mtk-vcodec/mtk_vcodec_dec.h  |  19 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  |   9 +-
 .../mtk-vcodec/mtk_vcodec_dec_stateful.c  | 629 
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  41 ++
 6 files changed, 754 insertions(+), 639 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index 37b94b555fa1..5dc588897d01 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -11,6 +11,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec_drv_if.o \
vdec_vpu_if.o \
mtk_vcodec_dec.o \
+   mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_pm.o \
 
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 2fdf23ce8ac4..f36219486700 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -24,65 +24,17 @@
 #include "vdec_drv_if.h"
 #include "mtk_vcodec_dec_pm.h"
 
-#define OUT_FMT_IDX0
-#define CAP_FMT_IDX3
-
-#define MTK_VDEC_MIN_W 64U
-#define MTK_VDEC_MIN_H 64U
 #define DFT_CFG_WIDTH  MTK_VDEC_MIN_W
 #define DFT_CFG_HEIGHT MTK_VDEC_MIN_H
 
-static const struct mtk_video_fmt mtk_video_formats[] = {
-   {
-   .fourcc = V4L2_PIX_FMT_H264,
-   .type = MTK_FMT_DEC,
-   .num_planes = 1,
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP8,
-   .type = MTK_FMT_DEC,
-   .num_planes = 1,
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP9,
-   .type = MTK_FMT_DEC,
-   .num_planes = 1,
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_MT21C,
-   .type = MTK_FMT_FRAME,
-   .num_planes = 2,
-   },
-};
-
-static const struct mtk_codec_framesizes mtk_vdec_framesizes[] = {
-   {
-   .fourcc = V4L2_PIX_FMT_H264,
-   .stepwise = {  MTK_VDEC_MIN_W, MTK_VDEC_MAX_W, 16,
-   MTK_VDEC_MIN_H, MTK_VDEC_MAX_H, 16 },
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP8,
-   .stepwise = {  MTK_VDEC_MIN_W, MTK_VDEC_MAX_W, 16,
-   MTK_VDEC_MIN_H, MTK_VDEC_MAX_H, 16 },
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP9,
-   .stepwise = {  MTK_VDEC_MIN_W, MTK_VDEC_MAX_W, 16,
-   MTK_VDEC_MIN_H, MTK_VDEC_MAX_H, 16 },
-   },
-};
-
-#define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_vdec_framesizes)
-#define NUM_FORMATS ARRAY_SIZE(mtk_video_formats)
-
-static const struct mtk_video_fmt *mtk_vdec_find_format(struct v4l2_format *f)
+static const struct mtk_video_fmt *mtk_vdec_find_format(struct v4l2_format *f,
+  const struct mtk_vcodec_dec_pdata *dec_pdata)
 {
const struct mtk_video_fmt *fmt;
unsigned int k;
 
-   for (k = 0; k < NUM_FORMATS; k++) {
-   fmt = _video_formats[k];
+   for (k = 0; k < dec_pdata->num_formats; k++) {
+   fmt = _pdata->vdec_formats[k];
if (fmt->fourcc == f->fmt.pix_mp.pixelformat)
return fmt;
}
@@ -99,390 +51,6 @@ static struct mtk_q_data *mtk_vdec_get_q_data(struct 
mtk_vcodec_ctx *ctx,
return >q_data[MTK_Q_DATA_DST];
 }
 
-/*
- * This function tries to clean all display buffers, the buffers will return
- * in display order.
- * Note the buffers returned from codec driver may still be in driver's
- * reference list.
- */
-static struct vb2_buffer *get_display_buffer(struct mtk_vcodec_ctx *ctx)
-{
-   struct vdec_fb *disp_frame_buffer = NULL;
-   struct mtk_video_dec_buf *dstbuf;
-
-   mtk_v4l2_debug(3, "[%d]", ctx->id);
-   if (vdec_if_get_param(ctx,
-   GET_PARAM_DISP_FRAME_BUFFER,
-   _frame_buffer)) {
-   mtk_v4l2_err("[%d]Cannot get param : 
GET_PARAM_DISP_FRAME_BUFFER",
-   ctx->id);
-   return NULL;
-

[RFCv1 09/12] media: mtk-vcodec: vdec: support stateless API

From: Yunfei Dong 

Support the stateless codec API that will be used by MT8183.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]
---
 drivers/media/platform/mtk-vcodec/Makefile|   2 +
 .../platform/mtk-vcodec/mtk_vcodec_dec.c  |  43 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec.h  |  11 +-
 .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 493 ++
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |   3 +
 5 files changed, 549 insertions(+), 3 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index a9e189af5ba4..f7c1d27a85d5 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -7,11 +7,13 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
 mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp8_if.o \
vdec/vdec_vp9_if.o \
+   vdec/vdec_h264_req_if.o \
mtk_vcodec_dec_drv.o \
vdec_drv_if.o \
vdec_vpu_if.o \
mtk_vcodec_dec.o \
mtk_vcodec_dec_stateful.o \
+   mtk_vcodec_dec_stateless.o \
mtk_vcodec_dec_pm.o \
mtk_vcodec_fw.o
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index f36219486700..d0fa2184dff7 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -423,7 +423,8 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
return -EINVAL;
 
pix_mp = >fmt.pix_mp;
-   if ((f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
+   if (!dec_pdata->uses_stateless_api &&
+   (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
vb2_is_busy(>m2m_ctx->out_q_ctx.q)) {
mtk_v4l2_err("out_q_ctx buffers already requested");
ret = -EBUSY;
@@ -460,6 +461,7 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
ctx->quantization = f->fmt.pix_mp.quantization;
ctx->xfer_func = f->fmt.pix_mp.xfer_func;
 
+   ctx->current_codec = fmt->fourcc;
if (ctx->state == MTK_STATE_FREE) {
ret = vdec_if_init(ctx, q_data->fmt->fourcc);
if (ret) {
@@ -471,6 +473,45 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
}
}
 
+   /* Tolerate both OUTPUT and CAPTURE queues for compatibility reasons */
+   if (dec_pdata->uses_stateless_api) {
+   ctx->picinfo.pic_w = pix_mp->width;
+   ctx->picinfo.pic_h = pix_mp->height;
+
+   ret = vdec_if_get_param(ctx, GET_PARAM_PIC_INFO, >picinfo);
+   if (ret) {
+   mtk_v4l2_err("[%d]Error!! Get GET_PARAM_PICTURE_INFO 
Fail",
+   ctx->id);
+   return -EINVAL;
+   }
+
+   ctx->last_decoded_picinfo = ctx->picinfo;
+   if (pix_mp->num_planes == 1) {
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
+   ctx->picinfo.fb_sz[0] +
+   ctx->picinfo.fb_sz[1];
+   ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
+   ctx->picinfo.buf_w;
+   } else {
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
+   ctx->picinfo.fb_sz[0];
+   ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
+   ctx->picinfo.buf_w;
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[1] =
+   ctx->picinfo.fb_sz[1];
+   ctx->q_data[MTK_Q_DATA_DST].bytesperline[1] =
+   ctx->picinfo.buf_w;
+   }
+
+   ctx->q_data[MTK_Q_DATA_DST].coded_width = ctx->picinfo.buf_w;
+   ctx->q_data[MTK_Q_DATA_DST].coded_height = ctx->picinfo.buf_h;
+   mtk_v4l2_debug(2, "[%d] vdec_if_init() num_plane = %d wxh=%dx%d 
pic wxh=%dx%d sz[0]=0x%x sz[1]=0x%x",
+   ctx->id, pix_mp->num_planes,
+   ctx->picinfo.buf_w, ctx->picinfo.buf_h,
+   ctx->picinfo.pic_w, ctx->picinfo.pic_h,
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[0],
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[1]);
+   }
return 0;
 }
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
index f9f5a7fa0bb1..1f8eaecdbdfb 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
+++

[RFCv1 11/12] media: mtk-vcodec: vdec: add media device if using stateless api

From: Yunfei Dong 

The stateless API requires a media device for issuing requests. Add one
if it turns out we are using it.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]
---
 drivers/media/platform/Kconfig|  1 +
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  | 40 +++
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  2 +
 3 files changed, 43 insertions(+)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 853330c642f1..f5476827259b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -247,6 +247,7 @@ config VIDEO_MEDIATEK_VCODEC
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
select VIDEO_MEDIATEK_VPU
+   select MEDIA_CONTROLLER
help
Mediatek video codec driver provides HW capability to
encode and decode in a range of video formats
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index ffa6f3d0869d..8be0c04f7e81 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_vcodec_drv.h"
 #include "mtk_vcodec_dec.h"
@@ -337,6 +338,31 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_event_workq;
}
 
+   if (dev->vdec_pdata->uses_stateless_api) {
+   dev->mdev_dec.dev = >dev;
+   strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME,
+   sizeof(dev->mdev_dec.model));
+
+   media_device_init(>mdev_dec);
+   dev->mdev_dec.ops = _vcodec_media_ops;
+   dev->v4l2_dev.mdev = >mdev_dec;
+
+   ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec,
+   dev->vfd_dec, MEDIA_ENT_F_PROC_VIDEO_DECODER);
+   if (ret) {
+   mtk_v4l2_err("Failed to register media controller");
+   goto err_reg_cont;
+   }
+
+   ret = media_device_register(>mdev_dec);
+   if (ret) {
+   mtk_v4l2_err("Failed to register media device");
+   goto err_media_reg;
+   }
+
+   mtk_v4l2_debug(0, "media registered as /dev/media%d",
+   vfd_dec->num);
+   }
ret = video_register_device(vfd_dec, VFL_TYPE_GRABBER, 0);
if (ret) {
mtk_v4l2_err("Failed to register video device");
@@ -349,6 +375,12 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
return 0;
 
 err_dec_reg:
+   if (dev->vdec_pdata->uses_stateless_api)
+   media_device_unregister(>mdev_dec);
+err_media_reg:
+   if (dev->vdec_pdata->uses_stateless_api)
+   v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec);
+err_reg_cont:
destroy_workqueue(dev->decode_workqueue);
 err_event_workq:
v4l2_m2m_release(dev->m2m_dev_dec);
@@ -362,6 +394,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
 }
 
 extern const struct mtk_vcodec_dec_pdata mtk_frame_8173_pdata;
+extern const struct mtk_vcodec_dec_pdata mtk_req_8183_pdata;
 
 static const struct of_device_id mtk_vcodec_match[] = {
{
@@ -379,6 +412,13 @@ static int mtk_vcodec_dec_remove(struct platform_device 
*pdev)
 
flush_workqueue(dev->decode_workqueue);
destroy_workqueue(dev->decode_workqueue);
+
+   if (media_devnode_is_registered(dev->mdev_dec.devnode)) {
+   media_device_unregister(>mdev_dec);
+   v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec);
+   media_device_cleanup(>mdev_dec);
+   }
+
if (dev->m2m_dev_dec)
v4l2_m2m_release(dev->m2m_dev_dec);
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 6ce7b3a14193..38e499bb7d2b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -353,6 +353,7 @@ struct mtk_vcodec_dec_pdata {
  * struct mtk_vcodec_dev - driver data
  * @v4l2_dev: V4L2 device to register video devices for.
  * @vfd_dec: Video device for decoder
+ * @mdev_dec: Media device for decoder
  * @vfd_enc: Video device for encoder.
  *
  * @m2m_dev_dec: m2m device for decoder
@@ -389,6 +390,7 @@ struct mtk_vcodec_dec_pdata {
 struct mtk_vcodec_dev {
struct v4l2_device v4l2_dev;
struct video_device *vfd_dec;
+   struct media_device mdev_dec;
struct video_device *vfd_enc;
 
struct v4l2_m2m_dev *m2m_dev_dec;
-- 
2.22.0.rc1.257.g3120a18244-goog

[RFCv1 10/12] media: mtk-vcodec: vdec: support stateless H.264 decoding

From: Yunfei Dong 

Add the firmware interface allowing to decode H.264 in a stateless
manner.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]
---
 .../mtk-vcodec/vdec/vdec_h264_req_if.c| 533 ++
 .../media/platform/mtk-vcodec/vdec_drv_if.c   |   4 +
 2 files changed, 537 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c

diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
new file mode 100644
index ..27874afac86b
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+
+#include "../vdec_drv_if.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_dec.h"
+#include "../mtk_vcodec_intr.h"
+#include "../vdec_vpu_if.h"
+#include "../vdec_drv_base.h"
+
+#define NAL_NON_IDR_SLICE  0x01
+#define NAL_IDR_SLICE  0x05
+#define NAL_H264_PPS   0x08
+#define NAL_TYPE(value)((value) & 0x1F)
+
+#define BUF_PREDICTION_SZ  (64 * 4096)
+
+#define MB_UNIT_LEN16
+
+/* motion vector size (bytes) for every macro block */
+#define HW_MB_STORE_SZ 64
+
+#define H264_MAX_FB_NUM17
+#define H264_MAX_MV_NUM32
+#define HDR_PARSING_BUF_SZ 1024
+
+/**
+ * struct mtk_h264_dpb_info  - h264 dpb information
+ * @y_dma_addr: Y bitstream physical address
+ * @c_dma_addr: CbCr bitstream physical address
+ * @reference_flag: reference picture flag (short/long term reference picture)
+ * @field: field picture flag
+ */
+struct mtk_h264_dpb_info {
+   dma_addr_t y_dma_addr;
+   dma_addr_t c_dma_addr;
+   int reference_flag;
+   int field;
+};
+
+/**
+ * struct mtk_h264_dec_slice_param  - parameters for decode current frame
+ */
+struct mtk_h264_dec_slice_param {
+   struct v4l2_ctrl_h264_sps   sps;
+   struct v4l2_ctrl_h264_pps   pps;
+   struct v4l2_ctrl_h264_scaling_matrixscaling_matrix;
+   struct v4l2_ctrl_h264_slice_param   slice_param;
+   struct v4l2_ctrl_h264_decode_param  decode_param;
+   struct mtk_h264_dpb_info h264_dpb_info[16];
+};
+
+/**
+ * struct h264_fb - h264 decode frame buffer information
+ * @vdec_fb_va  : virtual address of struct vdec_fb
+ * @y_fb_dma: dma address of Y frame buffer (luma)
+ * @c_fb_dma: dma address of C frame buffer (chroma)
+ * @poc : picture order count of frame buffer
+ * @reserved: for 8 bytes alignment
+ */
+struct h264_fb {
+   uint64_t vdec_fb_va;
+   uint64_t y_fb_dma;
+   uint64_t c_fb_dma;
+   int32_t poc;
+   uint32_t reserved;
+};
+
+/**
+ * struct vdec_h264_dec_info - decode information
+ * @dpb_sz : decoding picture buffer size
+ * @resolution_changed  : resoltion change happen
+ * @realloc_mv_buf : flag to notify driver to re-allocate mv buffer
+ * @cap_num_planes : number planes of capture buffer
+ * @bs_dma : Input bit-stream buffer dma address
+ * @y_fb_dma   : Y frame buffer dma address
+ * @c_fb_dma   : C frame buffer dma address
+ * @vdec_fb_va : VDEC frame buffer struct virtual address
+ */
+struct vdec_h264_dec_info {
+   uint32_t dpb_sz;
+   uint32_t resolution_changed;
+   uint32_t realloc_mv_buf;
+   uint32_t cap_num_planes;
+   uint64_t bs_dma;
+   uint64_t y_fb_dma;
+   uint64_t c_fb_dma;
+   uint64_t vdec_fb_va;
+};
+
+/**
+ * struct vdec_h264_vsi - shared memory for decode information exchange
+ *between VPU and Host.
+ *The memory is allocated by VPU then mapping to Host
+ *in vpu_dec_init() and freed in vpu_dec_deinit()
+ *by VPU.
+ *AP-W/R : AP is writer/reader on this item
+ *VPU-W/R: VPU is write/reader on this item
+ * @pred_buf_dma : HW working predication buffer dma address (AP-W, VPU-R)
+ * @mv_buf_dma   : HW working motion vector buffer dma address (AP-W, VPU-R)
+ * @dec  : decode information (AP-R, VPU-W)
+ * @pic  : picture information (AP-R, VPU-W)
+ * @crop : crop information (AP-R, VPU-W)
+ */
+struct vdec_h264_vsi {
+   uint64_t pred_buf_dma;
+   uint64_t mv_buf_dma[H264_MAX_MV_NUM];
+   struct vdec_h264_dec_info dec;
+   struct vdec_pic_info pic;
+   struct v4l2_rect crop;
+   struct mtk_h264_dec_slice_param h264_slice_param;
+};
+
+/**
+ * struct vdec_h264_slice_inst - h264 decoder instance
+ * @num_nalu :

[RFCv1 05/12] media: mtk-vcodec: support single-buffer frames

From: Yunfei Dong 

MT8183 will use a multi-planar format backed by a single buffer. Adapt
the existing code to be able to handle such frames instead of assuming
each frame is backed by two buffers.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 2175883e22d4..2fdf23ce8ac4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -130,8 +130,9 @@ static struct vb2_buffer *get_display_buffer(struct 
mtk_vcodec_ctx *ctx)
if (dstbuf->used) {
vb2_set_plane_payload(>vb.vb2_buf, 0,
ctx->picinfo.fb_sz[0]);
-   vb2_set_plane_payload(>vb.vb2_buf, 1,
-   ctx->picinfo.fb_sz[1]);
+   if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
+   vb2_set_plane_payload(>vb.vb2_buf, 1,
+   ctx->picinfo.fb_sz[1]);
 
mtk_v4l2_debug(2,
"[%d]status=%x queue id=%d to done_list %d",
@@ -402,7 +403,8 @@ static void mtk_vdec_worker(struct work_struct *work)
vdec_if_decode(ctx, NULL, NULL, _chg);
clean_display_buffer(ctx);
vb2_set_plane_payload(_buf_info->vb.vb2_buf, 0, 0);
-   vb2_set_plane_payload(_buf_info->vb.vb2_buf, 1, 0);
+   if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
+   vb2_set_plane_payload(_buf_info->vb.vb2_buf, 1, 0);
dst_buf->flags |= V4L2_BUF_FLAG_LAST;
v4l2_m2m_buf_done(_buf_info->vb, VB2_BUF_STATE_DONE);
clean_free_buffer(ctx);
@@ -1333,7 +1335,8 @@ static void vb2ops_vdec_stop_streaming(struct vb2_queue 
*q)
 
while ((dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx))) {
vb2_set_plane_payload(_buf->vb2_buf, 0, 0);
-   vb2_set_plane_payload(_buf->vb2_buf, 1, 0);
+   if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
+   vb2_set_plane_payload(_buf->vb2_buf, 1, 0);
v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_ERROR);
}
 
-- 
2.22.0.rc1.257.g3120a18244-goog

[RFCv1 04/12] media: mtk-vcodec: fix copyright indent

From: Yunfei Dong 

Minor identation fix for copyright notice in a few source files.

Signed-off-by: Yunfei Dong 
[acourbot: refactor, cleanup and split]
Signed-off-by: Alexandre Courbot 
---
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  | 26 +--
 .../platform/mtk-vcodec/mtk_vcodec_enc.c  | 26 +--
 .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c   | 24 -
 3 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 109c7578a8b2..76905e2d56a7 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -1,17 +1,17 @@
 /*
-* Copyright (c) 2016 MediaTek Inc.
-* Author: PC Chen 
-* Tiffany Lin 
-*
-* This program is free software; you can redistribute it and/or modify
-* it under the terms of the GNU General Public License version 2 as
-* published by the Free Software Foundation.
-*
-* This program is distributed in the hope that it will be useful,
-* but WITHOUT ANY WARRANTY; without even the implied warranty of
-* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-* GNU General Public License for more details.
-*/
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: PC Chen 
+ * Tiffany Lin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #ifndef _MTK_VCODEC_DRV_H_
 #define _MTK_VCODEC_DRV_H_
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 2d5a61c06287..32d8ce9c8f6e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -1,17 +1,17 @@
 /*
-* Copyright (c) 2016 MediaTek Inc.
-* Author: PC Chen 
-* Tiffany Lin 
-*
-* This program is free software; you can redistribute it and/or modify
-* it under the terms of the GNU General Public License version 2 as
-* published by the Free Software Foundation.
-*
-* This program is distributed in the hope that it will be useful,
-* but WITHOUT ANY WARRANTY; without even the implied warranty of
-* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-* GNU General Public License for more details.
-*/
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: PC Chen 
+ * Tiffany Lin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include 
 #include 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
index 39375b8ea27c..2fdae50173be 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
@@ -1,16 +1,16 @@
 /*
-* Copyright (c) 2016 MediaTek Inc.
-* Author: Tiffany Lin 
-*
-* This program is free software; you can redistribute it and/or modify
-* it under the terms of the GNU General Public License version 2 as
-* published by the Free Software Foundation.
-*
-* This program is distributed in the hope that it will be useful,
-* but WITHOUT ANY WARRANTY; without even the implied warranty of
-* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-* GNU General Public License for more details.
-*/
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Tiffany Lin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include 
 #include 
-- 
2.22.0.rc1.257.g3120a18244-goog

[RFCv1 01/12] media: mtk-vcodec: avoid unneeded pointer-to-long conversions

The interface used to communicate with the firmware casts pointers
into unsigned longs and back again in order to store private
references, all of this for pointers that remain purely in the kernel.
Replace these unsigned longs with void pointers to make the code a bit
sturdier and easier to follow.

Also simplify some interfaces by removing arguments that could be
infered from others.

Signed-off-by: Alexandre Courbot 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h   |  2 +-
 .../media/platform/mtk-vcodec/vdec/vdec_h264_if.c| 12 ++--
 drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c | 12 ++--
 drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c | 12 ++--
 drivers/media/platform/mtk-vcodec/vdec_drv_base.h|  8 
 drivers/media/platform/mtk-vcodec/vdec_drv_if.c  |  2 +-
 .../media/platform/mtk-vcodec/venc/venc_h264_if.c| 10 +-
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 10 +-
 drivers/media/platform/mtk-vcodec/venc_drv_base.h|  8 
 drivers/media/platform/mtk-vcodec/venc_drv_if.c  |  2 +-
 10 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 662a84b822af..5da42f555b52 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -281,7 +281,7 @@ struct mtk_vcodec_ctx {
 
const struct vdec_common_if *dec_if;
const struct venc_common_if *enc_if;
-   unsigned long drv_handle;
+   void *drv_handle;
 
struct vdec_pic_info picinfo;
int dpb_size;
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
index cdbcd6909728..2b29e004575d 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
@@ -274,7 +274,7 @@ static void get_dpb_size(struct vdec_h264_inst *inst, 
unsigned int *dpb_sz)
mtk_vcodec_debug(inst, "sz=%d", *dpb_sz);
 }
 
-static int vdec_h264_init(struct mtk_vcodec_ctx *ctx, unsigned long *h_vdec)
+static int vdec_h264_init(struct mtk_vcodec_ctx *ctx)
 {
struct vdec_h264_inst *inst = NULL;
int err;
@@ -303,7 +303,7 @@ static int vdec_h264_init(struct mtk_vcodec_ctx *ctx, 
unsigned long *h_vdec)
 
mtk_vcodec_debug(inst, "H264 Instance >> %p", inst);
 
-   *h_vdec = (unsigned long)inst;
+   ctx->drv_handle = inst;
return 0;
 
 error_deinit:
@@ -314,7 +314,7 @@ static int vdec_h264_init(struct mtk_vcodec_ctx *ctx, 
unsigned long *h_vdec)
return err;
 }
 
-static void vdec_h264_deinit(unsigned long h_vdec)
+static void vdec_h264_deinit(void *h_vdec)
 {
struct vdec_h264_inst *inst = (struct vdec_h264_inst *)h_vdec;
 
@@ -339,7 +339,7 @@ static int find_start_code(unsigned char *data, unsigned 
int data_sz)
return -1;
 }
 
-static int vdec_h264_decode(unsigned long h_vdec, struct mtk_vcodec_mem *bs,
+static int vdec_h264_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
struct vdec_fb *fb, bool *res_chg)
 {
struct vdec_h264_inst *inst = (struct vdec_h264_inst *)h_vdec;
@@ -459,8 +459,8 @@ static void vdec_h264_get_fb(struct vdec_h264_inst *inst,
list->count--;
 }
 
-static int vdec_h264_get_param(unsigned long h_vdec,
-  enum vdec_get_param_type type, void *out)
+static int vdec_h264_get_param(void *h_vdec, enum vdec_get_param_type type,
+  void *out)
 {
struct vdec_h264_inst *inst = (struct vdec_h264_inst *)h_vdec;
 
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c
index ba79136421ef..a13253242e90 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c
@@ -396,7 +396,7 @@ static void free_working_buf(struct vdec_vp8_inst *inst)
inst->vsi->dec.working_buf_dma = 0;
 }
 
-static int vdec_vp8_init(struct mtk_vcodec_ctx *ctx, unsigned long *h_vdec)
+static int vdec_vp8_init(struct mtk_vcodec_ctx *ctx)
 {
struct vdec_vp8_inst *inst;
int err;
@@ -427,7 +427,7 @@ static int vdec_vp8_init(struct mtk_vcodec_ctx *ctx, 
unsigned long *h_vdec)
get_hw_reg_base(inst);
mtk_vcodec_debug(inst, "VP8 Instance >> %p", inst);
 
-   *h_vdec = (unsigned long)inst;
+   ctx->drv_handle = inst;
return 0;
 
 error_deinit:
@@ -437,7 +437,7 @@ static int vdec_vp8_init(struct mtk_vcodec_ctx *ctx, 
unsigned long *h_vdec)
return err;
 }
 
-static int vdec_vp8_decode(unsigned long h_vdec, struct mtk_vcodec_mem *bs,
+static int vdec_vp8_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
   struct vdec_fb *fb, bool *res_chg)
 {
struct vdec_vp8_inst *inst = (struct vdec_vp8_inst

[RFCv1 07/12] media: mtk-vcodec: abstract firmware interface

From: Yunfei Dong 

MT8183's codec firwmare is run by a different remote processor from
MT8173. While the firmware interface is basically the same, the way to
invoke it differs. Abstract all firmware calls under a layer that will
allow us to handle both firmware types transparently.

Signed-off-by: Yunfei Dong 
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
[acourbot: refactor, cleanup and split]
---
 drivers/media/platform/mtk-vcodec/Makefile|   4 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  |  47 ++
 .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c   |   1 -
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |   5 +-
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |  46 ++---
 .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c   |   2 -
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 157 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.h |  36 
 .../platform/mtk-vcodec/mtk_vcodec_util.c |   1 -
 .../platform/mtk-vcodec/vdec/vdec_h264_if.c   |   1 -
 .../platform/mtk-vcodec/vdec/vdec_vp8_if.c|   1 -
 .../platform/mtk-vcodec/vdec/vdec_vp9_if.c|   1 -
 .../media/platform/mtk-vcodec/vdec_drv_base.h |   2 -
 .../media/platform/mtk-vcodec/vdec_drv_if.c   |   1 -
 .../media/platform/mtk-vcodec/vdec_vpu_if.c   |  10 +-
 .../media/platform/mtk-vcodec/vdec_vpu_if.h   |  11 +-
 .../platform/mtk-vcodec/venc/venc_h264_if.c   |  15 +-
 .../platform/mtk-vcodec/venc/venc_vp8_if.c|   8 +-
 .../media/platform/mtk-vcodec/venc_drv_if.c   |   1 -
 .../media/platform/mtk-vcodec/venc_vpu_if.c   |  15 +-
 .../media/platform/mtk-vcodec/venc_vpu_if.h   |   5 +-
 21 files changed, 270 insertions(+), 100 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index 5dc588897d01..a9e189af5ba4 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -13,7 +13,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
mtk_vcodec_dec.o \
mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_pm.o \
-
+   mtk_vcodec_fw.o
 
 mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc/venc_h264_if.o \
@@ -26,5 +26,3 @@ mtk-vcodec-enc-y := venc/venc_vp8_if.o \
 
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
-
-ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 5a31917da18c..2328bb9580be 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -28,7 +28,7 @@
 #include "mtk_vcodec_dec_pm.h"
 #include "mtk_vcodec_intr.h"
 #include "mtk_vcodec_util.h"
-#include "mtk_vpu.h"
+#include "mtk_vcodec_fw.h"
 
 #define VDEC_HW_ACTIVE 0x10
 #define VDEC_IRQ_CFG   0x11
@@ -85,22 +85,6 @@ static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void 
*priv)
return IRQ_HANDLED;
 }
 
-static void mtk_vcodec_dec_reset_handler(void *priv)
-{
-   struct mtk_vcodec_dev *dev = priv;
-   struct mtk_vcodec_ctx *ctx;
-
-   mtk_v4l2_err("Watchdog timeout!!");
-
-   mutex_lock(>dev_mutex);
-   list_for_each_entry(ctx, >ctx_list, list) {
-   ctx->state = MTK_STATE_ABORT;
-   mtk_v4l2_debug(0, "[%d] Change to state MTK_STATE_ERROR",
-   ctx->id);
-   }
-   mutex_unlock(>dev_mutex);
-}
-
 static int fops_vcodec_open(struct file *file)
 {
struct mtk_vcodec_dev *dev = video_drvdata(file);
@@ -152,21 +136,20 @@ static int fops_vcodec_open(struct file *file)
if (v4l2_fh_is_singular(>fh)) {
mtk_vcodec_dec_pw_on(>pm);
/*
-* vpu_load_firmware checks if it was loaded already and
-* does nothing in that case
+* Does nothing if firmware was already loaded.
 */
-   ret = vpu_load_firmware(dev->vpu_plat_dev);
+   ret = mtk_vcodec_fw_load_firmware(dev->fw_handler);
if (ret < 0) {
/*
 * Return 0 if downloading firmware successfully,
 * otherwise it is failed
 */
-   mtk_v4l2_err("vpu_load_firmware failed!");
+   mtk_v4l2_err("failed to load firmware!");
goto err_load_fw;
}
 
dev->dec_capability =
-   vpu_get_vdec_hw_capa(dev->vpu_plat_dev);
+   mtk_vcodec_fw_get_vdec_capa(dev->fw_handler);
mtk_v4l2_debug(0, "decoder capability %x", dev->dec_capability);
}
 
@@ -236,6 +219,8 @@ static int mtk_vcodec_probe(struct

[RFCv1 02/12] media: mtk-vcodec: remove unneeded proxy functions

We were getting the codec interface through a proxy function that does
not bring anything compared to just accessing the interface definition
directly, so just do that. Also make the decoder interfaces const.

Signed-off-by: Alexandre Courbot 
---
 .../media/platform/mtk-vcodec/vdec/vdec_h264_if.c|  9 +
 drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c |  9 +
 drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c |  9 +
 drivers/media/platform/mtk-vcodec/vdec_drv_if.c  | 12 ++--
 .../media/platform/mtk-vcodec/venc/venc_h264_if.c|  9 +
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c |  9 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c  |  8 
 7 files changed, 15 insertions(+), 50 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
index 2b29e004575d..185d8e7bdc87 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
@@ -493,16 +493,9 @@ static int vdec_h264_get_param(void *h_vdec, enum 
vdec_get_param_type type,
return 0;
 }
 
-static struct vdec_common_if vdec_h264_if = {
+const struct vdec_common_if vdec_h264_if = {
.init   = vdec_h264_init,
.decode = vdec_h264_decode,
.get_param  = vdec_h264_get_param,
.deinit = vdec_h264_deinit,
 };
-
-struct vdec_common_if *get_h264_dec_comm_if(void);
-
-struct vdec_common_if *get_h264_dec_comm_if(void)
-{
-   return _h264_if;
-}
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c
index a13253242e90..28475b8d27fe 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c
@@ -618,16 +618,9 @@ static void vdec_vp8_deinit(void *h_vdec)
kfree(inst);
 }
 
-static struct vdec_common_if vdec_vp8_if = {
+const struct vdec_common_if vdec_vp8_if = {
.init   = vdec_vp8_init,
.decode = vdec_vp8_decode,
.get_param  = vdec_vp8_get_param,
.deinit = vdec_vp8_deinit,
 };
-
-struct vdec_common_if *get_vp8_dec_comm_if(void);
-
-struct vdec_common_if *get_vp8_dec_comm_if(void)
-{
-   return _vp8_if;
-}
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c
index 65b88a2bef4c..f4af69c543ba 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c
@@ -1008,16 +1008,9 @@ static int vdec_vp9_get_param(void *h_vdec, enum 
vdec_get_param_type type,
return ret;
 }
 
-static struct vdec_common_if vdec_vp9_if = {
+const struct vdec_common_if vdec_vp9_if = {
.init   = vdec_vp9_init,
.decode = vdec_vp9_decode,
.get_param  = vdec_vp9_get_param,
.deinit = vdec_vp9_deinit,
 };
-
-struct vdec_common_if *get_vp9_dec_comm_if(void);
-
-struct vdec_common_if *get_vp9_dec_comm_if(void)
-{
-   return _vp9_if;
-}
diff --git a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
index 1e3778738f3b..dfe63bb39dbb 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
@@ -23,9 +23,9 @@
 #include "mtk_vcodec_dec_pm.h"
 #include "mtk_vpu.h"
 
-const struct vdec_common_if *get_h264_dec_comm_if(void);
-const struct vdec_common_if *get_vp8_dec_comm_if(void);
-const struct vdec_common_if *get_vp9_dec_comm_if(void);
+extern const struct vdec_common_if vdec_h264_if;
+extern const struct vdec_common_if vdec_vp8_if;
+extern const struct vdec_common_if vdec_vp9_if;
 
 int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 {
@@ -33,13 +33,13 @@ int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int 
fourcc)
 
switch (fourcc) {
case V4L2_PIX_FMT_H264:
-   ctx->dec_if = get_h264_dec_comm_if();
+   ctx->dec_if = _h264_if;
break;
case V4L2_PIX_FMT_VP8:
-   ctx->dec_if = get_vp8_dec_comm_if();
+   ctx->dec_if = _vp8_if;
break;
case V4L2_PIX_FMT_VP9:
-   ctx->dec_if = get_vp9_dec_comm_if();
+   ctx->dec_if = _vp9_if;
break;
default:
return -EINVAL;
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
index b6feb786bebf..eb015ce0fd3e 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -664,16 +664,9 @@ static int h264_enc_deinit(void *handle)
return ret;
 }
 
-static const struct venc_common_if venc_h264_if = {
+const struct venc_common_if venc_h264_if = {
.init =

[RFCv1 00/12] media: mtk-vcodec: support for MT8183 decoder

This series is a refactoring/split of the initial patch for MT8183 codec support
that was posted for Chrome OS [1] in order to make it upstreamable.

The line count has been significantly reduced compared to the initial patch,
although support for the MT8183 encoder is not here yet to limit the amount of
code to review.

Although the series applies on top of today's media tree, it will not compile
until support for the SCP is merged, hence the RFC status. Note also that the
H.264 structures used and implementation of the stateless codec API may not be
completely up-to-date. So the goal of this publication is to review the general
idea (especially split unto stateful and stateless ops), and maybe merge the
first 5 patches.

Patches 1-5 are cleanup/small fixes that came while working on this series. They
should be harmless and can be merged.

Patches 6 adds a layer of abstraction to some of the decoder operations.
Currently mtk-vcodec and MT8173 use the stateful codec API, but MT8183 is based
on a stateless model. So patch 6 isolates the ops specific to the stateful codec
so MT8173 and MT8183 can share a big part of the code.

Patch 7 abstracts the firmware interface, as MT8173 and MT8183 are controlled
by different interfaces (VPU or SCP). Patch 8 adds the firmware ops for MT8183.

Patch 9 and 10 add support for stateless decoders in the driver, and support for
stateless H.264 decoding respectively.

Patch 11 takes care of adding the media device for stateless codecs, and
patch 12 allows the MT8183 decoder to probe.

I am mostly expecting comments about the general direction, but of course more
in-depth reviews are also welcome.

[1] 
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1377757/

Alexandre Courbot (3):
  media: mtk-vcodec: avoid unneeded pointer-to-long conversions
  media: mtk-vcodec: remove unneeded proxy functions
  media: mtk-vcodec: constify formats

Yunfei Dong (9):
  media: mtk-vcodec: fix copyright indent
  media: mtk-vcodec: support single-buffer frames
  media: mtk-vcodec: move stateful ops into their own file
  media: mtk-vcodec: abstract firmware interface
  media: mtk-vcodec: add SCP firmware ops
  media: mtk-vcodec: vdec: support stateless API
  media: mtk-vcodec: vdec: support stateless H.264 decoding
  media: mtk-vcodec: vdec: add media device if using stateless api
  media: mtk-vcodec: enable MT8183 decoder

 drivers/media/platform/Kconfig|   1 +
 drivers/media/platform/mtk-vcodec/Makefile|   7 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec.c  | 751 +++---
 .../platform/mtk-vcodec/mtk_vcodec_dec.h  |  30 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  | 103 ++-
 .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c   |   1 -
 .../mtk-vcodec/mtk_vcodec_dec_stateful.c  | 629 +++
 .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 493 
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  81 +-
 .../platform/mtk-vcodec/mtk_vcodec_enc.c  |  45 +-
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  |  49 +-
 .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c   |  26 +-
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 208 +
 .../media/platform/mtk-vcodec/mtk_vcodec_fw.h |  38 +
 .../platform/mtk-vcodec/mtk_vcodec_util.c |   1 -
 .../platform/mtk-vcodec/vdec/vdec_h264_if.c   |  22 +-
 .../mtk-vcodec/vdec/vdec_h264_req_if.c| 533 +
 .../platform/mtk-vcodec/vdec/vdec_vp8_if.c|  22 +-
 .../platform/mtk-vcodec/vdec/vdec_vp9_if.c|  22 +-
 .../media/platform/mtk-vcodec/vdec_drv_base.h |  10 +-
 .../media/platform/mtk-vcodec/vdec_drv_if.c   |  19 +-
 .../media/platform/mtk-vcodec/vdec_vpu_if.c   |  10 +-
 .../media/platform/mtk-vcodec/vdec_vpu_if.h   |  11 +-
 .../platform/mtk-vcodec/venc/venc_h264_if.c   |  34 +-
 .../platform/mtk-vcodec/venc/venc_vp8_if.c|  27 +-
 .../media/platform/mtk-vcodec/venc_drv_base.h |   8 +-
 .../media/platform/mtk-vcodec/venc_drv_if.c   |  11 +-
 .../media/platform/mtk-vcodec/venc_vpu_if.c   |  15 +-
 .../media/platform/mtk-vcodec/venc_vpu_if.h   |   5 +-
 29 files changed, 2328 insertions(+), 884 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h
 create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c

-- 
2.22.0.rc1.257.g3120a18244-goog

Re: [PATCH v3 1/3] PCI: Introduce pcibios_ignore_alignment_request





On 5/28/19 12:36 AM, Oliver wrote:

On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio  wrote:


Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine whether or not to ignore alignment requests for PCI resources.

The existing behavior is to simply ignore alignment requests when
PCI_PROBE_ONLY is set. This is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.

Signed-off-by: Shawn Anastasio 
---
  drivers/pci/pci.c   | 9 +++--
  include/linux/pci.h | 1 +
  2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8abc843b1615..8207a09085d1 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5882,6 +5882,11 @@ resource_size_t __weak pcibios_default_alignment(void)
 return 0;
  }

+int __weak pcibios_ignore_alignment_request(void)
+{
+   return pci_has_flag(PCI_PROBE_ONLY);
+}
+
  #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
  static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
  static DEFINE_SPINLOCK(resource_alignment_lock);
@@ -5906,9 +5911,9 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
 p = resource_alignment_param;
 if (!*p && !align)
 goto out;
-   if (pci_has_flag(PCI_PROBE_ONLY)) {
+   if (pcibios_ignore_alignment_request()) {
 align = 0;
-   pr_info_once("PCI: Ignoring requested alignments 
(PCI_PROBE_ONLY)\n");
+   pr_info_once("PCI: Ignoring requested alignments\n");
 goto out;
 }


I think the logic here is questionable to begin with. If the user has
explicitly requested re-aligning a resource via the command line then
we should probably do it even if PCI_PROBE_ONLY is set. When it breaks
they get to keep the pieces.

That said, the real issue here is that PCI_PROBE_ONLY probably
shouldn't be set under qemu/kvm. Under the other hypervisor (PowerVM)
hotplugged devices are configured by firmware before it's passed to
the guest and we need to keep the FW assignments otherwise things
break. QEMU however doesn't do any BAR assignments and relies on that
being handled by the guest. At boot time this is done by SLOF, but
Linux only keeps SLOF around until it's extracted the device-tree.
Once that's done SLOF gets blown away and the kernel needs to do it's
own BAR assignments. I'm guessing there's a hack in there to make it
work today, but it's a little surprising that it works at all...

Interesting, I wasn't aware that hotplugged devices are configured
by the hypervisor on PowerVM. That at least means that this patch is
wrong as-is since it won't handle that properly. Definitely seems like
there will need to be different behavior here depending on the hypervisor.

That being said, wouldn't PCI_PROBE_ONLY still be set on pseries/kvm
(at least for initial boot) to observe SLOF's original BAR assignments?
Perhaps it should be un-set after initial PCI init?



IIRC Sam Bobroff was looking at hotplug under pseries recently so he
might have something to add. He's sick at the moment, but I'll ask him
to take a look at this once he's back among the living


Good to know. I'll await his comments before continuing here.


diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4a5a84d7bdd4..47471dcdbaf9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1990,6 +1990,7 @@ static inline void pcibios_penalize_isa_irq(int irq, int 
active) {}
  int pcibios_alloc_irq(struct pci_dev *dev);
  void pcibios_free_irq(struct pci_dev *dev);
  resource_size_t pcibios_default_alignment(void);
+int pcibios_ignore_alignment_request(void);

  #ifdef CONFIG_HIBERNATE_CALLBACKS
  extern struct dev_pm_ops pcibios_pm_ops;
--
2.20.1

KASAN: invalid-free in tomoyo_realpath_from_path

2019-05-27 Thread syzbot


Hello,

syzbot found the following crash on:

HEAD commit:f4aa8012 cxgb4: Make t4_get_tp_e2c_map static
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=173328baa0
kernel config:  https://syzkaller.appspot.com/x/.config?x=d137eb988ffd93c3
dashboard link: https://syzkaller.appspot.com/bug?extid=9742b1c6c7aedf18beda
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9742b1c6c7aedf18b...@syzkaller.appspotmail.com

==
BUG: KASAN: double-free or invalid-free in  
tomoyo_realpath_from_path+0x1de/0x7a0 security/tomoyo/realpath.c:319


CPU: 1 PID: 11697 Comm: syz-executor.3 Not tainted 5.2.0-rc1+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
 kasan_report_invalid_free+0x65/0xa0 mm/kasan/report.c:279
 __kasan_slab_free+0x13a/0x150 mm/kasan/common.c:430
 kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
 __cache_free mm/slab.c:3432 [inline]
 kfree+0xcf/0x220 mm/slab.c:3755
 tomoyo_realpath_from_path+0x1de/0x7a0 security/tomoyo/realpath.c:319
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_check_open_permission+0x2a8/0x3f0 security/tomoyo/file.c:771
 tomoyo_file_open security/tomoyo/tomoyo.c:319 [inline]
 tomoyo_file_open+0xa9/0xd0 security/tomoyo/tomoyo.c:314
 security_file_open+0x71/0x300 security/security.c:1458
 do_dentry_open+0x373/0x1250 fs/open.c:765
 vfs_open+0xa0/0xd0 fs/open.c:887
 do_last fs/namei.c:3416 [inline]
 path_openat+0x10e9/0x46d0 fs/namei.c:3533
 do_filp_open+0x1a1/0x280 fs/namei.c:3563
 do_sys_open+0x3fe/0x5d0 fs/open.c:1070
 __do_sys_open fs/open.c:1088 [inline]
 __se_sys_open fs/open.c:1083 [inline]
 __x64_sys_open+0x7e/0xc0 fs/open.c:1083
 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4571f0
Code: 31 c0 e9 45 ff ff ff 0f 1f 00 80 3f 00 0f 84 f7 00 00 00 55 53 b9 02  
00 00 00 be 00 08 09 00 89 c8 48 81 ec 98 00 00 00 0f 05 <48> 3d 00 f0 ff  
ff 48 89 c3 0f 87 e9 00 00 00 85 db 0f 88 2f 01 00

RSP: 002b:7ffee56b06a0 EFLAGS: 0206 ORIG_RAX: 0002
RAX: ffda RBX: 000cb440 RCX: 004571f0
RDX: 000c RSI: 00090800 RDI: 7ffee56b1880
RBP: 0002 R08: 0001 R09: 57133940
R10:  R11: 0206 R12: 7ffee56b1880
R13: 7ffee56b1870 R14:  R15: 7ffee56b1880

Allocated by task 11696:
 save_stack+0x23/0x90 mm/kasan/common.c:71
 set_track mm/kasan/common.c:79 [inline]
 __kasan_kmalloc mm/kasan/common.c:489 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
 __do_kmalloc mm/slab.c:3660 [inline]
 __kmalloc+0x15c/0x740 mm/slab.c:3669
 kmalloc include/linux/slab.h:552 [inline]
 tomoyo_realpath_from_path+0xcd/0x7a0 security/tomoyo/realpath.c:277
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_check_open_permission+0x2a8/0x3f0 security/tomoyo/file.c:771
 tomoyo_file_open security/tomoyo/tomoyo.c:319 [inline]
 tomoyo_file_open+0xa9/0xd0 security/tomoyo/tomoyo.c:314
 security_file_open+0x71/0x300 security/security.c:1458
 do_dentry_open+0x373/0x1250 fs/open.c:765
 vfs_open+0xa0/0xd0 fs/open.c:887
 do_last fs/namei.c:3416 [inline]
 path_openat+0x10e9/0x46d0 fs/namei.c:3533
 do_filp_open+0x1a1/0x280 fs/namei.c:3563
 do_sys_open+0x3fe/0x5d0 fs/open.c:1070
 __do_sys_open fs/open.c:1088 [inline]
 __se_sys_open fs/open.c:1083 [inline]
 __x64_sys_open+0x7e/0xc0 fs/open.c:1083
 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 11696:
 save_stack+0x23/0x90 mm/kasan/common.c:71
 set_track mm/kasan/common.c:79 [inline]
 __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
 kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
 __cache_free mm/slab.c:3432 [inline]
 kfree+0xcf/0x220 mm/slab.c:3755
 tomoyo_realpath_from_path+0x1de/0x7a0 security/tomoyo/realpath.c:319
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_check_open_permission+0x2a8/0x3f0 security/tomoyo/file.c:771
 tomoyo_file_open security/tomoyo/tomoyo.c:319 [inline]
 tomoyo_file_open+0xa9/0xd0 security/tomoyo/tomoyo.c:314
 security_file_open+0x71/0x300 security/security.c:1458
 do_dentry_open+0x373/0x1250 fs/open.c:765
 vfs_open+0xa0/0xd0 fs/open.c:887
 do_last fs/namei.c:3416 [inline]
 path_openat+0x10e9/0x46d0 fs/namei.c:3533
 do_filp_open+0x1a1/0x280 fs/namei.c:3563
 do_sys_open+0x3fe/0x5d0 fs/open.c:1070
 __do_sys_open fs/open.c:1088 [inline]
 __se_sys_open fs/open.c:1083 [inline]
 __x64_sys_open+0x7e/0xc0 fs/open.c:1083

Re: [PATCH v3 14/16] powerpc/32: implement fast entry for syscalls on BOOKE

Christophe Leroy  writes:
> Le 23/05/2019 à 09:00, Christophe Leroy a écrit :
>
> [...]
>
>>> arch/powerpc/kernel/head_fsl_booke.o: In function `SystemCall':
>>> arch/powerpc/kernel/head_fsl_booke.S:416: undefined reference to 
>>> `kvmppc_handler_BOOKE_INTERRUPT_SYSCALL_SPRN_SRR1'
>>> Makefile:1052: recipe for target 'vmlinux' failed
>>>
 +.macro SYSCALL_ENTRY trapno intno
 +    mfspr    r10, SPRN_SPRG_THREAD
 +#ifdef CONFIG_KVM_BOOKE_HV
 +BEGIN_FTR_SECTION
 +    mtspr    SPRN_SPRG_WSCRATCH0, r10
 +    stw    r11, THREAD_NORMSAVE(0)(r10)
 +    stw    r13, THREAD_NORMSAVE(2)(r10)
 +    mfcr    r13    /* save CR in r13 for now   */
 +    mfspr    r11, SPRN_SRR1
 +    mtocrf    0x80, r11    /* check MSR[GS] without clobbering reg */
 +    bf    3, 1975f
 +    b    kvmppc_handler_BOOKE_INTERRUPT_\intno\()_SPRN_SRR1
>>>
>>> It seems to me that the "_SPRN_SRR1" on the end of this line
>>> isn't meant to be there...  However, it still fails to link with that
>>> removed.
>
> It looks like I missed the macro expansion.
>
> The called function should be kvmppc_handler_8_0x01B
>
> Seems like kisskb doesn't build any config like this.

I thought we did, ie:

http://kisskb.ellerman.id.au/kisskb/buildresult/13817941/

But clearly something is missing to trigger the bug.

cheers

Re: [PATCH v3 1/3] PCI: Introduce pcibios_ignore_alignment_request

2019-05-27 Thread Oliver

On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio  wrote:
>
> Introduce a new pcibios function pcibios_ignore_alignment_request
> which allows the PCI core to defer to platform-specific code to
> determine whether or not to ignore alignment requests for PCI resources.
>
> The existing behavior is to simply ignore alignment requests when
> PCI_PROBE_ONLY is set. This is behavior is maintained by the
> default implementation of pcibios_ignore_alignment_request.
>
> Signed-off-by: Shawn Anastasio 
> ---
>  drivers/pci/pci.c   | 9 +++--
>  include/linux/pci.h | 1 +
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 8abc843b1615..8207a09085d1 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5882,6 +5882,11 @@ resource_size_t __weak pcibios_default_alignment(void)
> return 0;
>  }
>
> +int __weak pcibios_ignore_alignment_request(void)
> +{
> +   return pci_has_flag(PCI_PROBE_ONLY);
> +}
> +
>  #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
>  static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
>  static DEFINE_SPINLOCK(resource_alignment_lock);
> @@ -5906,9 +5911,9 @@ static resource_size_t 
> pci_specified_resource_alignment(struct pci_dev *dev,
> p = resource_alignment_param;
> if (!*p && !align)
> goto out;
> -   if (pci_has_flag(PCI_PROBE_ONLY)) {
> +   if (pcibios_ignore_alignment_request()) {
> align = 0;
> -   pr_info_once("PCI: Ignoring requested alignments 
> (PCI_PROBE_ONLY)\n");
> +   pr_info_once("PCI: Ignoring requested alignments\n");
> goto out;
> }

I think the logic here is questionable to begin with. If the user has
explicitly requested re-aligning a resource via the command line then
we should probably do it even if PCI_PROBE_ONLY is set. When it breaks
they get to keep the pieces.

That said, the real issue here is that PCI_PROBE_ONLY probably
shouldn't be set under qemu/kvm. Under the other hypervisor (PowerVM)
hotplugged devices are configured by firmware before it's passed to
the guest and we need to keep the FW assignments otherwise things
break. QEMU however doesn't do any BAR assignments and relies on that
being handled by the guest. At boot time this is done by SLOF, but
Linux only keeps SLOF around until it's extracted the device-tree.
Once that's done SLOF gets blown away and the kernel needs to do it's
own BAR assignments. I'm guessing there's a hack in there to make it
work today, but it's a little surprising that it works at all...

IIRC Sam Bobroff was looking at hotplug under pseries recently so he
might have something to add. He's sick at the moment, but I'll ask him
to take a look at this once he's back among the living

> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 4a5a84d7bdd4..47471dcdbaf9 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1990,6 +1990,7 @@ static inline void pcibios_penalize_isa_irq(int irq, 
> int active) {}
>  int pcibios_alloc_irq(struct pci_dev *dev);
>  void pcibios_free_irq(struct pci_dev *dev);
>  resource_size_t pcibios_default_alignment(void);
> +int pcibios_ignore_alignment_request(void);
>
>  #ifdef CONFIG_HIBERNATE_CALLBACKS
>  extern struct dev_pm_ops pcibios_pm_ops;
> --
> 2.20.1
>

Re: [PATCH 1/4] arm64: module: create module allocations without exec permissions

2019-05-27 Thread Anshuman Khandual




On 05/23/2019 03:52 PM, Ard Biesheuvel wrote:
> Now that the core code manages the executable permissions of code
> regions of modules explicitly, it is no longer necessary to create

I guess the permission transition for various module sections happen
through module_enable_[ro|nx]() after allocating via module_alloc().

> the module vmalloc regions with RWX permissions, and we can create
> them with RW- permissions instead, which is preferred from a
> security perspective.

Makes sense. Will this be followed in all architectures now ?

> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  arch/arm64/kernel/module.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 2e4e3915b4d0..88f0ed31d9aa 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -41,7 +41,7 @@ void *module_alloc(unsigned long size)
>  
>   p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>   module_alloc_base + MODULES_VSIZE,
> - gfp_mask, PAGE_KERNEL_EXEC, 0,
> + gfp_mask, PAGE_KERNEL, 0,
>   NUMA_NO_NODE, __builtin_return_address(0));
>  
>   if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -57,7 +57,7 @@ void *module_alloc(unsigned long size)
>*/
>   p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>   module_alloc_base + SZ_4G, GFP_KERNEL,
> - PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
> + PAGE_KERNEL, 0, NUMA_NO_NODE,
>   __builtin_return_address(0));
>  
>   if (p && (kasan_module_alloc(p, size) < 0)) {
> 

Which just makes sure that PTE_PXN never gets dropped while creating
these mappings.

Re: [PATCH] userfaultfd: selftest: fix compiler warning

2019-05-27 Thread Mike Rapoport

On Mon, May 27, 2019 at 03:18:59PM +, Alakesh Haloi wrote:
> Fixes following compiler warning
> 
> userfaultfd.c: In function ‘usage’:
> userfaultfd.c:126:2: warning: format not a string literal and no format
>   arguments [-Wformat-security]
>   fprintf(stderr, examples);
> 
> Signed-off-by: Alakesh Haloi 

Reviewed-by: Mike Rapoport 

> ---
>  tools/testing/selftests/vm/userfaultfd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/vm/userfaultfd.c 
> b/tools/testing/selftests/vm/userfaultfd.c
> index 5d1db824f73a..b3e6497b080c 100644
> --- a/tools/testing/selftests/vm/userfaultfd.c
> +++ b/tools/testing/selftests/vm/userfaultfd.c
> @@ -123,7 +123,7 @@ static void usage(void)
>   fprintf(stderr, "Supported : anon, hugetlb, "
>   "hugetlb_shared, shmem\n\n");
>   fprintf(stderr, "Examples:\n\n");
> - fprintf(stderr, examples);
> + fprintf(stderr, "%s", examples);
>   exit(1);
>  }
> 
> -- 
> 2.17.1
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 0/5] firmware: Add support for loading compressed files

2019-05-27 Thread Takashi Iwai

On Mon, 20 May 2019 11:26:42 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> this is a patch set to add the support for loading compressed firmware
> files.
> 
> The primary motivation is to reduce the storage size; e.g. currently
> the amount of /lib/firmware on my machine counts up to 419MB, and this
> can be reduced to 130MB file compression.  No bad deal.
> 
> The feature adds only fallback to the compressed file, so it should
> work as it was as long as the normal firmware file is present.  The
> f/w loader decompresses the content, so that there is no change needed
> in the caller side.
> 
> Currently only XZ format is supported.  A caveat is that the kernel XZ
> helper code supports only CRC32 (or none) integrity check type, so
> you'll have to compress the files via xz -C crc32 option.
> 
> The patch set begins with a few other improvements and refactoring,
> followed by the compression support.
> 
> In addition to this, dracut needs a small fix to deal with the *.xz
> files.
> 
> Also, the latest patchset is found in topic/fw-decompress branch of my
> sound.git tree:
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> 
> 
> thanks,
> 
> Takashi

Luis, any comments on the patchset?


thanks,

Takashi

> 
> ===
> 
> Takashi Iwai (5):
>   firmware: Free temporary page table after vmapping
>   firmware: Unify the paged buffer release helper
>   firmware: Use kvmalloc for page tables
>   firmware: Factor out the paged buffer handling code
>   firmware: Add support for loading compressed files
> 
>  drivers/base/firmware_loader/Kconfig|  18 +++
>  drivers/base/firmware_loader/fallback.c |  63 ++
>  drivers/base/firmware_loader/firmware.h |  16 ++-
>  drivers/base/firmware_loader/main.c | 212 
> +---
>  4 files changed, 235 insertions(+), 74 deletions(-)
> 
> -- 
> 2.16.4
>

Re: MIPS r4k cache operations with SMP enabled

2019-05-27 Thread Chris Packham

On 28/05/19 2:52 PM, Chris Packham wrote:
> Hi,
> 
> I'm trying to port a fairly old Broadcom integrated chip (BCM6818) to
> the latest Linux kernel using the mips/bmips support.
> 
> The chip has a BMIPS4355 core. This has two "thread processors" (cpu
> cores) with separate I-caches but a shared D-cache.
> 
> I've got things booting but I encounter the following BUG()
> 
> BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
> caller is blast_dcache16+0x24/0x154
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-at1 #5
> Stack : 0036 8008d0d0 806a 807c 80754e10 000b 80754684
> 8f831c8c
>   8090 8f828424 807986e7 8071348c  10008f00 8f831c30
> 7fb69e2a
>     8092 0056 2335  807a
> 
>   6d6d3a20  0056 73776170   10008f01
> 807c
>   8079 2cc2  8090 0010 8f83198c 
> 8090
>   ...
> Call Trace:
> [<8001c208>] show_stack+0x30/0x100
> [<8063282c>] dump_stack+0x9c/0xd0
> [<802f1cec>] debug_smp_processor_id+0xfc/0x110
> [<8002e274>] blast_dcache16+0x24/0x154
> [<80122978>] map_vm_area+0x58/0x70
> [<80123888>] __vmalloc_node_range+0x1fc/0x2b4
> [<80123b54>] vmalloc+0x44/0x50
> [<807d15d0>] jffs2_zlib_init+0x24/0x94
> [<807d1354>] jffs2_compressors_init+0x10/0x30
> [<807d151c>] init_jffs2_fs+0x68/0xf8
> [<8001016c>] do_one_initcall+0x7c/0x1f0
> [<807bee30>] kernel_init_freeable+0x17c/0x258
> [<80650d1c>] kernel_init+0x10/0xf8
> [<80015e6c>] ret_from_kernel_thread+0x14/0x1c
> 
> In blast_dcache16 current_cpu_data is used which invokes
> smp_processor_id() triggering the BUG(). I can fix this by sprinkling
> preempt_disable/preempt_enable through arch/mips/mm/c-r4k.c but that
> seems kind of wrong. Does anyone have any suggestion as to the right way
> to avoid this BUG()?
> 
> Thanks,
> Chris

I think the following might do the trick

 8< 
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 5166e38cd1c6..1fa7f093b59c 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -559,14 +559,19 @@ static inline int has_valid_asid(const struct 
mm_struct *mm, unsigned int type)
 return 0;
  }

-static void r4k__flush_cache_vmap(void)
+static inline void local_r4k_flush_cache(void *args)
  {
 r4k_blast_dcache();
  }

+void r4k__flush_cache_vmap(void)
+{
+   r4k_on_each_cpu(R4K_INDEX, local_r4k_flush_cache, NULL);
+}
+
  static void r4k__flush_cache_vunmap(void)
  {
-   r4k_blast_dcache();
+   r4k_on_each_cpu(R4K_INDEX, local_r4k_flush_cache, NULL);
  }

  /*
@@ -1758,6 +1763,43 @@ static int __init cca_setup(char *str)
 return 0;
  }
 8< 

The rest of the call sites for r4k_blast_dcache() already run with 
preemption disabled.

Re: [PATCH v4 00/30] coresight: Support for ACPI bindings

2019-05-27 Thread Leo Yan

Hi Suzuki,

On Wed, May 22, 2019 at 11:34:33AM +0100, Suzuki K Poulose wrote:
> This series adds the support for CoreSight devices on ACPI based
> platforms. The device connections are encoded as _DSD graph property[0],
> with CoreSight specific extensions to indicate the direction of data
> flow as described in [1]. Components attached to CPUs are listed
> as child devices of the corresponding CPU, removing explicit links
> to the CPU like we do in the DT.
> 
> The majority of the series cleans up the driver and prepares the subsystem
> for platform agnostic firwmare probing, naming scheme, searching etc.
> 
> We introduce platform independent helpers to parse the platform supplied
> information. Thus we rename the platform handling code from:
>   of_coresight.c  => coresight-platform.c
> 
> The CoreSight driver creates shadow devices that appear on the Coresight
> bus, in addition to the real devices (e.g, AMBA bus devices). The name
> of these devices match the real device. This makes the device name
> a bit cryptic for ACPI platform. So this series also introduces a generic
> platform agnostic device naming scheme for the shadow Coresight devices.
> Towards this we also make changes to the way we lookup devices to resolve
> the connections, as we can't use the names to identify the devices. So,
> we use the "fwnode_handle" of the real device for the device lookups.
> Towards that we clean up the drivers to keep track of the "CoreSight"
> device rather than the "real" device. However, all real operations,
> like DMA allocation, Power management etc. must be performed on
> the real device which is the parent of the shadow device.
> 
> Finally we add the support for parsing the ACPI platform data. The power
> management support is missing in the ACPI (and this is not specific to
> CoreSight). The firmware must ensure that the respective power domains
> are turned on.
> 
> Applies on v5.2-rc1
> 
> Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on
> top of [2]. You would need to make sure that the debug power domain is
> turned on before the Linux kernel boots. (e.g, connect the DS-5 to the
> Juno board while at UEFI). arm32 code is only compile tested.

After I applied this patch set, I found all device names under
'/sys/bus/event_source/devices/cs_etm/sinks/' have been changed as
below on my DB410c board:
# ls /sys/bus/event_source/devices/cs_etm/sinks/
tmc_etf0  tmc_etr0  tpiu0

This leads to below command failure when open PMU device:
# perf record -e cs_etm/@826000.etr/ --per-thread uname
failed to set sink "826000.etr" on event cs_etm/@826000.etr/ with 2 (No such 
file or directory)

I must use below command so that perf can match string with the
device name under '/sys/bus/event_source/devices/cs_etm/sinks/':
# perf record -e cs_etm/@tmc_etr0/ --per-thread uname

Seems to me, this is an unexpected change and when I worked on the
patch set v2, IIRC that version still can use '826000.etr' to open PMU
device.

Please help confirm for this.  Thanks!

Leo.

Re: [PATCH net 4/4] net/udpgso_bench_tx: audit error queue

2019-05-27 Thread Fred Klassen




> On May 27, 2019, at 6:15 PM, Willem de Bruijn 
>  wrote:
>> I wanted to discuss whether or not to attach a buffer to the
>> recvmsg(fd, , MSG_ERRQUEUE). Without it, I have
>> MSG_TRUNC errors in my msg_flags. Either I have to add
>> a buffer, or ignore that error flag.
> 
> Either sounds reasonable. It is an expected and well understood
> message if underprovisioning the receive data buffer.
> 

I’ll stick with setting up buffers. It will fail if there are any bugs 
introduced in buffer copy routines.

> 
> The netdev list is archived and available through various websites,
> like lore.kernel.org/netdev . As well as the patches with comments at
> patchwork.ozlabs.org/project/netdev/list
> 

Much better. Sure beats hunting down lost emails.


>> I have been wondering about xmit_more
>> myself. I don’t think it changes anything for software timestamps,
>> but it may with hardware timestamps.
> 
> It arguably makes the software timestamp too early if taken on the
> first segment, as the NIC is only informed of all the new descriptors
> when the last segment is written and the doorbell is rung.
> 

Totally makes sense. Possibly this can be improved software TX
timestamps by delaying until just before ring buffer is advanced.
It would have to be updated in each driver. I may have a look at
this once I am complete this patch. Hopefully that one will be a bit
smoother. 

>>> Can you elaborate on this suspected memory leak?
>> 
>> A user program cannot free a zerocopy buffer until it is reported as free.
>> If zerocopy events are not reported, that could be a memory leak.
>> 
>> I may have a fix. I have added a -P option when I am running an audit.
>> It doesn’t appear to affect performance, and since implementing it I have
>> received all error messages expected for both timestamp and zerocopy.
>> 
>> I am still testing.
> 
> I see, a userspace leak from lack of completion notification.
> 
> If the issue is a few missing notifications at the end of the run,
> then perhaps cfg_waittime_ms is too short.
> 

I’ll get back to you when I have tested this more thoroughly. Early results
suggest that adding the -P poll() option has fixed it without any appreciable
performance hit. I’ll share raw results with you, and we can make a final
decision together.

>> Should the test have failed at this point? I did return an error(), but
>> the script kept running.
> 
> This should normally be cause for test failure, I think yes. Though
> it's fine to send the code for review and possibly even merge, so that
> I can take a look.
> 

Sounds like udpgso_bench.sh needs a ’set -e’ to ensure it stops on
first error.

[PATCH v3] coredump: Split pipe command whitespace before expanding template

2019-05-27 Thread Paul Wise

Save the offsets of the start of each argument to avoid having to
update pointers to each argument after every corename krealloc and
to avoid having to duplicate the memory for the dump command.

Executable names containing spaces were previously being expanded from
%e or %E and then split in the middle of the filename. This is incorrect
behaviour since an argument list can represent arguments with spaces.

The splitting could lead to extra arguments being passed to the core dump
handler that it might have interpreted as options or ignored completely.

Core dump handlers that are not aware of this Linux kernel issue will be
using %e or %E without considering that it may be split and so they will
be vulnerable to processes with spaces in their names breaking their
argument list. If their internals are otherwise well written, such as
if they are written in shell but quote arguments, they will work better
after this change than before. If they are not well written, then there
is a slight chance of breakage depending on the details of the code but
they will already be fairly broken by the split filenames.

Core dump handlers that are aware of this Linux kernel issue will be
placing %e or %E as the last item in their core_pattern and then
aggregating all of the remaining arguments into one, separated by
spaces. Alternatively they will be obtaining the filename via other
methods. Both of these will be compatible with the new arrangement.

A side effect from this change is that unknown template types
(for example %z) result in an empty argument to the dump handler
instead of the argument being dropped. This is a desired change as:

It is easier for dump handlers to process empty arguments than dropped
ones, especially if they are written in shell or don't pass each template
item with a preceding command-line option in order to differentiate
between individual template types. Most core_patterns in the wild do not
use options so they can confuse different template types (especially
numeric ones) if an earlier one gets dropped in old kernels. If the
kernel introduces a new template type and a core_pattern uses it, the
core dump handler might not expect that the argument can be dropped in
old kernels.

For example, this can result in security issues when %d is dropped in old
kernels. This happened with the corekeeper package in Debian and resulted
in the interface between corekeeper and Linux having to be rewritten to
use command-line options to differentiate between template types.

The core_pattern for most core dump handlers is written by the handler
author who would generally not insert unknown template types so this
change should be compatible with all the core dump handlers that exist.

Fixes: 74aadce98605
Reported-by: Jakub Wilk 
Reported-in: https://bugs.debian.org/924398
Reported-by: Paul Wise 
Reported-in: 
https://lore.kernel.org/linux-fsdevel/c8b7ecb8508895bf4adb62a748e2ea2c71854597.ca...@bonedaddy.net/
Suggested-by: Jakub Wilk 
Signed-off-by: Paul Wise 
---
 fs/coredump.c | 44 +++-
 1 file changed, 39 insertions(+), 5 deletions(-)

Changelog:
v3 Adjust footer fields, drop obvious comment
v2 Fix build failure due to typo after variable renaming

diff --git a/fs/coredump.c b/fs/coredump.c
index e42e17e55bfd..b1ea7dfbd149 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -187,11 +188,13 @@ static int cn_print_exe_file(struct core_name *cn)
  * name into corename, which must have space for at least
  * CORENAME_MAX_SIZE bytes plus one byte for the zero terminator.
  */
-static int format_corename(struct core_name *cn, struct coredump_params *cprm)
+static int format_corename(struct core_name *cn, struct coredump_params *cprm,
+  size_t **argv, int *argc)
 {
const struct cred *cred = current_cred();
const char *pat_ptr = core_pattern;
int ispipe = (*pat_ptr == '|');
+   bool was_space = false;
int pid_in_pattern = 0;
int err = 0;
 
@@ -201,12 +204,35 @@ static int format_corename(struct core_name *cn, struct 
coredump_params *cprm)
return -ENOMEM;
cn->corename[0] = '\0';
 
-   if (ispipe)
+   if (ispipe) {
+   int argvs = sizeof(core_pattern) / 2;
+   (*argv) = kmalloc_array(argvs, sizeof(**argv), GFP_KERNEL);
+   if (!(*argv))
+   return -ENOMEM;
+   (*argv)[(*argc)++] = 0;
++pat_ptr;
+   }
 
/* Repeat as long as we have more pattern to process and more output
   space */
while (*pat_ptr) {
+   /*
+* Split on spaces before doing template expansion so that
+* %e and %E don't get split if they have spaces in them
+*/
+   if (ispipe) {
+   if (isspace(*pat_ptr)) {
+

[PATCH v2] phy: renesas: rcar-gen2: Fix memory leak at error paths

2019-05-27 Thread Yoshihiro Shimoda

This patch fixes memory leak at error paths of the probe function.
In for_each_child_of_node, if the loop returns, the driver should
call of_put_node() before returns.

Reported-by: Julia Lawall 
Fixes: 1233f59f745 ("phy: Renesas R-Car Gen2 PHY driver")
Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 Changes from v1 (https://patchwork.kernel.org/patch/10831295/):
 - Rebase on renesas-drivers.git / renesas-drivers-2019-05-21-v5.2-rc1 tag.
 - Add Geert-san's Reviewed-by tag.

 drivers/phy/renesas/phy-rcar-gen2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/renesas/phy-rcar-gen2.c 
b/drivers/phy/renesas/phy-rcar-gen2.c
index 8dc5710..2926e49 100644
--- a/drivers/phy/renesas/phy-rcar-gen2.c
+++ b/drivers/phy/renesas/phy-rcar-gen2.c
@@ -391,6 +391,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
error = of_property_read_u32(np, "reg", _num);
if (error || channel_num > 2) {
dev_err(dev, "Invalid \"reg\" property\n");
+   of_node_put(np);
return error;
}
channel->select_mask = select_mask[channel_num];
@@ -406,6 +407,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
   data->gen2_phy_ops);
if (IS_ERR(phy->phy)) {
dev_err(dev, "Failed to create PHY\n");
+   of_node_put(np);
return PTR_ERR(phy->phy);
}
phy_set_drvdata(phy->phy, phy);
-- 
2.7.4

linux-next: Tree for May 28

2019-05-27 Thread Stephen Rothwell

Hi all,

Changes since 20190524:

The drm-fixes tree lost its build failure.

The akpm-current tree gained a build failure due to an interaction with
the ftrace tree for which I reverted 2 commits.

Non-merge commits (relative to Linus' tree): 2262
 2431 files changed, 83504 insertions(+), 36801 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, an allmodconfig 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. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 290 trees (counting Linus' and 70 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 (cd6c84d8f0cd Linux 5.2-rc2)
Merging fixes/master (2bbacd1a9278 Merge tag 'kconfig-v5.2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kspp-gustavo/for-next/kspp (034e673710d3 platform/x86: acer-wmi: Mark 
expected switch fall-throughs)
Merging kbuild-current/fixes (4c1ceed49be1 kconfig: tests: fix recursive 
inclusion unit test)
Merging arc-current/for-curr (4c70850aeb2e ARC: [plat-hsdk]: Add missing FIFO 
size entry in GMAC node)
Merging arm-current/fixes (e17b1af96b2a ARM: 8857/1: efi: enable CP15 DMB 
instructions before cleaning the cache)
Merging arm64-fixes/for-next/fixes (edbcf50eb8ae arm64: insn: Add 
BUILD_BUG_ON() for invalid masks)
Merging m68k-current/for-linus (fdd20ec8786a Documentation/features/time: Mark 
m68k having modern-timekeeping)
Merging powerpc-fixes/fixes (8b909e354870 powerpc/kexec: Fix loading of kernel 
+ initramfs with kexec_file_load())
Merging sparc/master (54dee406374c Merge tag 'arm64-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (3e66b7cc50ef net: tulip: de4x5: Drop redundant 
MODULE_DEVICE_TABLE())
Merging bpf/master (bd95e678e0f6 bpf: sockmap, fix use after free from sleep in 
psock backlog workqueue)
Merging ipsec/master (af8f3fb7fb07 net: stmmac: dma channel control register 
need to be init first)
Merging netfilter/master (3e66b7cc50ef net: tulip: de4x5: Drop redundant 
MODULE_DEVICE_TABLE())
Merging ipvs/master (e633508a9528 netfilter: nft_fib: Fix existence check 
support)
Merging wireless-drivers/master (903869bd10e6 ipv4/igmp: fix build error if 
!CONFIG_IP_MULTICAST)
Merging mac80211/master (33d915d9e8ce {nl,mac}80211: allow 4addr AP operation 
on crypto controlled devices)
Merging rdma-fixes/for-rc (619122be3d40 RDMA/hns: Fix PD memory leak for 
internal allocation)
Merging sound-current/for-linus (0fbf21c3b36a ALSA: hda/realtek - Enable 
micmute LED for Huawei laptops)
Merging sound-asoc-fixes/for-linus (20a5f9c8649d Merge branch 'asoc-5.2' into 
asoc-linus)
Merging regmap-fixes/for-linus (38ee2a8cc70e Merge branch 'regmap-5.2' into 
regmap-linus)
Merging regulator-fixes/for-linus (bb509baa7fec Merge branch 'regulator-5.2' 
into regulator-linus)
Merging spi-fixes/for-linus (da33d0c685f9 Merge branch 'spi-5.2' into spi-linus)
Merging pci-current/for-linus (a188339ca5a3 Linux 5.2-rc1)
Merging driver-core.current/driver-core-linus (cd6c84d8f0cd Linux 5.2-rc2)
Merging tty.current/tty-linus (a1ad1cc9704f vt/fbcon: deinitialize resources in 
visual_init() after failed memory allocation)
Merging usb.current/usb-linus (a47686636d84 media: smsusb: better handle 
optional alignment)
Merging usb-gadget-fixes/fixes (072684e8c58d USB: gadget: f_hid: fix deadlock 
in f_hidg_write())
Merging

[PATCH 1/1] arm64: dts: rockchip: add core dtsi file for RK3399Pro SoCs

2019-05-27 Thread Jianqun Xu

This patch adds core dtsi file for Rockchip RK3399Pro SoCs,
include rk3399.dtsi. Also enable these nodes:
- dfi/dmc for ddr devfreq
- pcie/pcie_phy
- sdhci/sdio/emmc/sdmmc

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/rk3399pro.dtsi | 111 
 1 file changed, 111 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399pro.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399pro.dtsi
new file mode 100644
index ..62f67f857c45
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399pro.dtsi
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
+
+#include "rk3399.dtsi"
+
+/ {
+   compatible = "rockchip,rk3399pro";
+
+   xin32k: xin32k {
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+   clock-output-names = "xin32k";
+   #clock-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   center-supply = <_log>;
+   upthreshold = <40>;
+   downdifferential = <20>;
+   system-status-freq = <
+   /*system status freq(KHz)*/
+   SYS_STATUS_NORMAL   80
+   SYS_STATUS_REBOOT   528000
+   SYS_STATUS_SUSPEND  20
+   SYS_STATUS_VIDEO_1080P  20
+   SYS_STATUS_VIDEO_4K 60
+   SYS_STATUS_VIDEO_4K_10B 80
+   SYS_STATUS_PERFORMANCE  80
+   SYS_STATUS_BOOST40
+   SYS_STATUS_DUALVIEW 60
+   SYS_STATUS_ISP  60
+   >;
+   vop-pn-msch-readlatency = <
+   /* plane_number  readlatency */
+   0   0
+   4   0x20
+   >;
+   vop-bw-dmc-freq = <
+   /* min_bw(MB/s) max_bw(MB/s) freq(KHz) */
+   0   762  20
+   763 1893 40
+   18943012 528000
+   3013980
+   >;
+   auto-min-freq = <20>;
+};
+
+_phy {
+   status = "okay";
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   ep-gpios = < RK_PB4 GPIO_ACTIVE_HIGH>;
+   num-lanes = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clkreqn_cpm>;
+   status = "okay";
+};
+
+ {
+   bus-width = <8>;
+   mmc-hs400-1_8v;
+   supports-emmc;
+   non-removable;
+   keep-power-in-suspend;
+   mmc-hs400-enhanced-strobe;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <15000>;
+   clock-freq-min-max = <20 15000>;
+   supports-sdio;
+   bus-width = <4>;
+   disable-wp;
+   cap-sd-highspeed;
+   cap-sdio-irq;
+   keep-power-in-suspend;
+   mmc-pwrseq = <_pwrseq>;
+   non-removable;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus4 _cmd _clk>;
+   sd-uhs-sdr104;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <15000>;
+   clock-freq-min-max = <40 15000>;
+   supports-sd;
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   disable-wp;
+   num-slots = <1>;
+   vqmmc-supply = <_sd>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _cd _bus4>;
+   status = "okay";
+};
-- 
2.17.1

Re: [RESEND PATCH 0/3] Allow custom PCI resource alignment on pseries

2019-05-27 Thread Oliver

On Tue, May 28, 2019 at 2:09 PM Shawn Anastasio  wrote:
>
>
>
> On 5/27/19 11:01 PM, Oliver wrote:
> > On Tue, May 28, 2019 at 8:56 AM Shawn Anastasio  wrote:
> >>
> >> Hello all,
> >>
> >> This patch set implements support for user-specified PCI resource
> >> alignment on the pseries platform for hotplugged PCI devices.
> >> Currently on pseries, PCI resource alignments specified with the
> >> pci=resource_alignment commandline argument are ignored, since
> >> the firmware is in charge of managing the PCI resources. In the
> >> case of hotplugged devices, though, the kernel is in charge of
> >> configuring the resources and should obey alignment requirements.
> >
> > Are you using hotplug to work around SLOF (the OF we use under qemu)
> > not aligning BARs to 64K? It looks like there is a commit in SLOF to
> > fix that 
> > (https://git.qemu.org/?p=SLOF.git;a=commit;f=board-qemu/slof/pci-phb.fs;h=1903174472f8800caf50c959b304501b4c01153c).
> >
>
> No, my application actually requires PCI hotplug at run-time.
>
> >> The current behavior of ignoring the alignment for hotplugged devices
> >> results in sub-page BARs landing between page boundaries and
> >> becoming un-mappable from userspace via the VFIO framework.
> >> This issue was observed on a pseries KVM guest with hotplugged
> >> ivshmem devices.
> >
> >> With these changes, users can specify an appropriate
> >> pci=resource_alignment argument on boot for devices they wish to use
> >> with VFIO.
> >>
> >> In the future, this could be extended to provide page-aligned
> >> resources by default for hotplugged devices, similar to what is done
> >> on powernv by commit 382746376993 ("powerpc/powernv: Override
> >> pcibios_default_alignment() to force PCI devices to be page aligned").
> >
> > Can we make aligning the BARs to PAGE_SIZE the default behaviour? The
> > BAR assignment process is complex enough as-is so I'd rather we didn't
> > add another platform hack into the mix.
>
> Absolutely. This will still require the existing changes so that the
> custom alignment isn't flat-out ignored on pseries, but I can set
> it to default to PAGE_SIZE as well, similar to how it's done on PowerNV.
> I've just pushed a v3 to fix a typo and I'll incorporate this change
> in v4.

I was thinking we could get rid of the ppcmd callback and do it in
kernel/pci-common.c. PowerNV is the only platform that implements the
callback and the pseries implementation is going to be identical so I
don't think there's much of point in keeping the callback.

> >> Feedback is appreciated.
> >>
> >> Thanks,
> >> Shawn
> >>
> >> Shawn Anastasio (3):
> >>PCI: Introduce pcibios_ignore_alignment_request
> >>powerpc/64: Enable pcibios_after_init hook on ppc64
> >>powerpc/pseries: Allow user-specified PCI resource alignment after
> >>  init
> >>
> >>   arch/powerpc/include/asm/machdep.h |  6 --
> >>   arch/powerpc/kernel/pci-common.c   |  9 +
> >>   arch/powerpc/kernel/pci_64.c   |  4 
> >>   arch/powerpc/platforms/pseries/setup.c | 22 ++
> >>   drivers/pci/pci.c  |  9 +++--
> >>   5 files changed, 46 insertions(+), 4 deletions(-)
> >>
> >> --
> >> 2.20.1
> >>

RE: [EXT] Re: [V3 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support

2019-05-27 Thread Peng Ma

Hi Vinod

Sorry to replay so late.
The dpaa2 qdma driver is based on FSL_MC_BUS and FSL_MC_DPIO, so It will used 
those two drivers
Functions or structs. This patch provides some necessary functions and structs 
for qdma driver(next patch: dpaa2-qdma.c)
The dpaa2 driver is not only to write some register on driver side but also 
need enable FSL_MC_BUS and FSL_MC_DPIO to
call some functions provided by them. Such as: mc_encode_cmd_header, 
mc_send_command etc. I will clear up this driver
again. And send V4 to review, thanks for your review.

Best Regards,
Peng
>-Original Message-
>From: Vinod Koul 
>Sent: 2019年4月26日 20:46
>To: Peng Ma 
>Cc: dan.j.willi...@intel.com; Leo Li ;
>linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org
>Subject: [EXT] Re: [V3 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data
>Path DMA Interface) support
>
>Caution: EXT Email
>
>On 09-04-19, 15:22, Peng Ma wrote:
>
>Subject missed PATCH tag!
>
>> The MC exports the DPDMAI object as an interface to operate the DPAA2
>> QDMA
>
>whats MC, DPDMAI, DPAA2
>
[Peng Ma] MC: Management Complex
DPDMAI: Data Path DMA Interface
DPAA2: Data Path Acceleration Architecture, Second Generation
I will explain them on next version.
>> Engine. The DPDMAI enables sending frame-based requests to QDMA and
>> receiving back confirmation response on transaction completion,
>> utilizing the DPAA2 QBMan infrastructure. DPDMAI object provides up to
>> two priorities for processing QDMA requests.
>
>> +int dpdmai_open(struct fsl_mc_io *mc_io,
>> + u32 cmd_flags,
>> + int dpdmai_id,
>> + u16 *token)
>
>could be written as:
>
>int dpdmai_open(struct fsl_mc_io *mc_io, u32 cmd_flags,
>int dpdmai_id, u16 *token)
>
>Looks neater, right? It would be to reread coding guidelines and run checkpatch
>with --strict on this
>
[Peng Ma] Ok, got it.
>
>> +{
>> + struct fsl_mc_command cmd = { 0 };
>
>where is this defined?
[Peng Ma] include/linux/fsl/mc.h
>
>> + struct dpdmai_cmd_open *cmd_params;
>> + int err;
>> +
>> + /* prepare command */
>> + cmd.header = mc_encode_cmd_header(DPDMAI_CMDID_OPEN,
>> +   cmd_flags,
>> +   0);
>> +
>> + cmd_params = (struct dpdmai_cmd_open *)cmd.params;
>
>I dont like casts, can you explain
[Peng Ma] If I didn't use the casts, There are two case:
1: struct fsl_mc_command cmd_org = { 0 };
  Struct fsl_mc_command *cmd = _org;
  In this case, we will define one more temporary variable in the stack.
2: Struct fsl_mc_command *cmd = kmalloc();
  In this case, we will alloc some memory, It may be produce memory
Fragmentation. Those functions will be called on driver init It is not 
necessary 
use this case to those function.
>
>> + cmd_params->dpdmai_id = cpu_to_le32(dpdmai_id);
>> +
>> + /* send command to mc*/
>> + err = mc_send_command(mc_io, );
>> + if (err)
>> + return err;
>> +
>> + /* retrieve response parameters */
>> + *token = mc_cmd_hdr_read_token();
>> + return 0;
>> +}
>
>who will call this API?
>
[Peng Ma] This file is not a driver, some of functions define in this file, the 
dma driver(dpaa2-qdma.c) will call some of those API and I will
delete unuseless API in the future.
>> +int dpdmai_create(struct fsl_mc_io *mc_io,
>> +   u32 cmd_flags,
>> +   const struct dpdmai_cfg *cfg,
>> +   u16 *token)
>> +{
>> + struct fsl_mc_command cmd = { 0 };
>> + int err;
>> +
>> + /* prepare command */
>> + cmd.header = mc_encode_cmd_header(DPDMAI_CMDID_CREATE,
>> +   cmd_flags,
>> +   0);
>
>why waste a line, last arg can be in previous line!
>
[Peng Ma] sorry, I will remove it.
>> +int dpdmai_get_tx_queue(struct fsl_mc_io *mc_io,
>> + u32 cmd_flags,
>> + u16 token,
>> + u8 priority,
>> + struct dpdmai_tx_queue_attr *attr) {
>> + struct fsl_mc_command cmd = { 0 };
>> + struct dpdmai_cmd_queue *cmd_params;
>> + struct dpdmai_rsp_get_tx_queue *rsp_params;
>> + int err;
>> +
>> + /* prepare command */
>> + cmd.header =
>mc_encode_cmd_header(DPDMAI_CMDID_GET_TX_QUEUE,
>> +   cmd_flags,
>> +   token);
>> +
>> + cmd_params = (struct dpdmai_cmd_queue *)cmd.params;
>> + cmd_params->queue = priority;
>> +
>> + /* send command to mc*/
>> + err = mc_send_command(mc_io, );
>> + if (err)
>> + return err;
>> +
>> + /* retrieve response parameters */
>> +
>> + rsp_params = (struct dpdmai_rsp_get_tx_queue *)cmd.params;
>> + attr->fqid = le32_to_cpu(rsp_params->fqid);
>> +
>> + return 0;
>> +}
>
>Okay this file does not use any of dmaengine apis, is this a dmaengine driver?
[Peng Ma] please the previous comment.
>
>> diff --git

Re: [RFC] printk/sysrq: Don't play with console_loglevel

2019-05-27 Thread Sergey Senozhatsky

On (05/28/19 13:15), Sergey Senozhatsky wrote:
> On (05/28/19 01:24), Dmitry Safonov wrote:
> [..]
> > While handling sysrq the console_loglevel is bumped to default to print
> > sysrq headers. It's done to print sysrq messages with WARNING level for
> > consumers of /proc/kmsg, though it sucks by the following reasons:
> > - changing console_loglevel may produce tons of messages (especially on
> >   bloated with debug/info prints systems)
> > - it doesn't guarantee that the message will be printed as printk may
> >   deffer the actual console output from buffer (see the comment near
> >   printk() in kernel/printk/printk.c)
> > 
> > Provide KERN_UNSUPPRESSED printk() annotation for such legacy places.
> > Make sysrq print the headers unsuppressed instead of changing
> > console_loglevel.
> 
> I've been thinking about this a while ago... So what I thought back
> then was that affected paths are atomic: sysrq, irqs, NMI, etc. Well
> at leasted it seemed to be so.

Ahh.. OK, now I sort of remember why I gave up on this idea (see [1]
at the bottom, when it comes to uv_nmi_dump_state()) - printk_NMI and
printk-safe redirections.

NMI
loglevel = NEW
printk -> printk_safe_nmi
loglevel = OLD

iret

IRQ
flush printk_safe_nmi -> printk
// At this point we don't remember about
// loglevel manipulation anymore
iret

We, probably, still need some flags to pass the "this was supposed to
be an important messages" info from printk-safe to normal printk. On
the other hand, if NMI printk-s then it's something rather important,
so we probably better print it anyway and avoid suppress_message_printing()
check for messages which are coming from printk-NMI buffers. To some
extent, it's the same with printk-safe: we don't use it unless we have
a very good reason. So if there is something in printk-safe buffers
then it better end up on consoles. So, maybe, we still can use that
per-CPU printk_context thing.

[1] https://lore.kernel.org/lkml/20180601044050.GA5687@jagdpanzerIV/

-ss

Re: [PATCH] list_lru: fix memory leak in __memcg_init_list_lru_node

2019-05-27 Thread Shakeel Butt

On Mon, May 27, 2019 at 9:32 PM Shakeel Butt  wrote:
>
> Syzbot reported following memory leak:
>
> da RBX: 0003 RCX: 00441f79
> BUG: memory leak
> unreferenced object 0x888114f26040 (size 32):
>   comm "syz-executor626", pid 7056, jiffies 4294948701 (age 39.410s)
>   hex dump (first 32 bytes):
> 40 60 f2 14 81 88 ff ff 40 60 f2 14 81 88 ff ff  @`..@`..
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
> [<18f36b56>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 
> [inline]
> [<18f36b56>] slab_post_alloc_hook mm/slab.h:439 [inline]
> [<18f36b56>] slab_alloc mm/slab.c:3326 [inline]
> [<18f36b56>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
> [<55b9a1a5>] kmalloc include/linux/slab.h:547 [inline]
> [<55b9a1a5>] __memcg_init_list_lru_node+0x58/0xf0 
> mm/list_lru.c:352
> [<1356631d>] memcg_init_list_lru_node mm/list_lru.c:375 [inline]
> [<1356631d>] memcg_init_list_lru mm/list_lru.c:459 [inline]
> [<1356631d>] __list_lru_init+0x193/0x2a0 mm/list_lru.c:626
> [] alloc_super+0x2e0/0x310 fs/super.c:269
> [<9023adcf>] sget_userns+0x94/0x2a0 fs/super.c:609
> [<52182cd8>] sget+0x8d/0xb0 fs/super.c:660
> [<06c24238>] mount_nodev+0x31/0xb0 fs/super.c:1387
> [<06016a76>] fuse_mount+0x2d/0x40 fs/fuse/inode.c:1236
> [<9a61ec1d>] legacy_get_tree+0x27/0x80 fs/fs_context.c:661
> [<96cd9ef8>] vfs_get_tree+0x2e/0x120 fs/super.c:1476
> [<5b8f472d>] do_new_mount fs/namespace.c:2790 [inline]
> [<5b8f472d>] do_mount+0x932/0xc50 fs/namespace.c:3110
> [] ksys_mount+0xab/0x120 fs/namespace.c:3319
> [<18f8c8ee>] __do_sys_mount fs/namespace.c: [inline]
> [<18f8c8ee>] __se_sys_mount fs/namespace.c:3330 [inline]
> [<18f8c8ee>] __x64_sys_mount+0x26/0x30 fs/namespace.c:3330
> [] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
> [<43d74ca0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> This is a simple off by one bug on the error path.
>
> Reported-by: syzbot+f90a420dfe2b1b03c...@syzkaller.appspotmail.com
> Signed-off-by: Shakeel Butt 

Forgot to add:

Fixes: 60d3fd32a7a9 ("list_lru: introduce per-memcg lists")
Cc: sta...@vger.kernel.org # 4.0+

> ---
>  mm/list_lru.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/list_lru.c b/mm/list_lru.c
> index 0bdf3152735e..92870be4a322 100644
> --- a/mm/list_lru.c
> +++ b/mm/list_lru.c
> @@ -358,7 +358,7 @@ static int __memcg_init_list_lru_node(struct 
> list_lru_memcg *memcg_lrus,
> }
> return 0;
>  fail:
> -   __memcg_destroy_list_lru_node(memcg_lrus, begin, i - 1);
> +   __memcg_destroy_list_lru_node(memcg_lrus, begin, i);
> return -ENOMEM;
>  }
>
> --
> 2.22.0.rc1.257.g3120a18244-goog
>

[PATCH] list_lru: fix memory leak in __memcg_init_list_lru_node

2019-05-27 Thread Shakeel Butt

Syzbot reported following memory leak:

da RBX: 0003 RCX: 00441f79
BUG: memory leak
unreferenced object 0x888114f26040 (size 32):
  comm "syz-executor626", pid 7056, jiffies 4294948701 (age 39.410s)
  hex dump (first 32 bytes):
40 60 f2 14 81 88 ff ff 40 60 f2 14 81 88 ff ff  @`..@`..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[<18f36b56>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 
[inline]
[<18f36b56>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<18f36b56>] slab_alloc mm/slab.c:3326 [inline]
[<18f36b56>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<55b9a1a5>] kmalloc include/linux/slab.h:547 [inline]
[<55b9a1a5>] __memcg_init_list_lru_node+0x58/0xf0 mm/list_lru.c:352
[<1356631d>] memcg_init_list_lru_node mm/list_lru.c:375 [inline]
[<1356631d>] memcg_init_list_lru mm/list_lru.c:459 [inline]
[<1356631d>] __list_lru_init+0x193/0x2a0 mm/list_lru.c:626
[] alloc_super+0x2e0/0x310 fs/super.c:269
[<9023adcf>] sget_userns+0x94/0x2a0 fs/super.c:609
[<52182cd8>] sget+0x8d/0xb0 fs/super.c:660
[<06c24238>] mount_nodev+0x31/0xb0 fs/super.c:1387
[<06016a76>] fuse_mount+0x2d/0x40 fs/fuse/inode.c:1236
[<9a61ec1d>] legacy_get_tree+0x27/0x80 fs/fs_context.c:661
[<96cd9ef8>] vfs_get_tree+0x2e/0x120 fs/super.c:1476
[<5b8f472d>] do_new_mount fs/namespace.c:2790 [inline]
[<5b8f472d>] do_mount+0x932/0xc50 fs/namespace.c:3110
[] ksys_mount+0xab/0x120 fs/namespace.c:3319
[<18f8c8ee>] __do_sys_mount fs/namespace.c: [inline]
[<18f8c8ee>] __se_sys_mount fs/namespace.c:3330 [inline]
[<18f8c8ee>] __x64_sys_mount+0x26/0x30 fs/namespace.c:3330
[] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
[<43d74ca0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

This is a simple off by one bug on the error path.

Reported-by: syzbot+f90a420dfe2b1b03c...@syzkaller.appspotmail.com
Signed-off-by: Shakeel Butt 
---
 mm/list_lru.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/list_lru.c b/mm/list_lru.c
index 0bdf3152735e..92870be4a322 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -358,7 +358,7 @@ static int __memcg_init_list_lru_node(struct list_lru_memcg 
*memcg_lrus,
}
return 0;
 fail:
-   __memcg_destroy_list_lru_node(memcg_lrus, begin, i - 1);
+   __memcg_destroy_list_lru_node(memcg_lrus, begin, i);
return -ENOMEM;
 }
 
-- 
2.22.0.rc1.257.g3120a18244-goog

[PATCH] vt: configurable number of console devices

2019-05-27 Thread Trevor Bourget

Having 63 vt devices for embedded systems might be overkill,
so provide a configuration MAX_NR_CONSOLES to allow this
consumption to be reduced.

Signed-off-by: Trevor Bourget 
---
 drivers/tty/Kconfig | 9 +
 include/uapi/linux/vt.h | 4 
 2 files changed, 13 insertions(+)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 3b1d312bb175..98e21589f4af 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -42,6 +42,15 @@ config VT
  If unsure, say Y, or else you won't be able to do much with your new
  shiny Linux system :-)
 
+config MAX_NR_CONSOLES
+   int "Maximum number of consoles to permit"
+   depends on VT
+   range 1 63
+   default "63"
+   ---help---
+ The maximum number of consoles that can be used.
+ The default is 63.
+
 config CONSOLE_TRANSLATIONS
depends on VT
default y
diff --git a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
index e9d39c48520a..3567dd239758 100644
--- a/include/uapi/linux/vt.h
+++ b/include/uapi/linux/vt.h
@@ -8,9 +8,13 @@
  * resizing).
  */
 #define MIN_NR_CONSOLES 1   /* must be at least 1 */
+#ifdef CONFIG_MAX_NR_CONSOLES
+#define MAX_NR_CONSOLES CONFIG_MAX_NR_CONSOLES
+#else
 #define MAX_NR_CONSOLES63  /* serial lines start at 64 */
/* Note: the ioctl VT_GETSTATE does not work for
   consoles 16 and higher (since it returns a short) */
+#endif
 
 /* 0x56 is 'V', to avoid collision with termios and kd */
 
-- 
2.22.0.rc1.257.g3120a18244-goog

Re: [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response

2019-05-27 Thread Alim Akhtar

Hi Avri

On 5/21/19 1:54 PM, Avri Altman wrote:
> struct ufs_dev_cmd is the main container that supports device management
> commands. In the case of a read descriptor request, we assume that the
> proper space was allocated in dev_cmd to hold the returning descriptor.
> 
> This is no longer true, as there are flows that doesn't use dev_cmd
> for device management requests, and was wrong in the first place.
> 
Can you please put some light on those flows? Are those platform 
specific? Just curious.
> fixes: d44a5f98bb49 (ufs: query descriptor API)
> 
> Signed-off-by: Avri Altman 
> ---
>   drivers/scsi/ufs/ufshcd.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 8c1c551..3fe3029 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1917,7 +1917,8 @@ int ufshcd_copy_query_response(struct ufs_hba *hba, 
> struct ufshcd_lrb *lrbp)
>   memcpy(_res->upiu_res, >ucd_rsp_ptr->qr, QUERY_OSF_SIZE);
>   
>   /* Get the descriptor */
> - if (lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
> + if (hba->dev_cmd.query.descriptor &&
> + lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
>   u8 *descp = (u8 *)lrbp->ucd_rsp_ptr +
>   GENERAL_UPIU_REQUEST_SIZE;
>   u16 resp_len;
> 
This change looks ok to me. I hope you have tested this patch.
Reviewed-by: Alim Akhtar

Re: [RFC] printk/sysrq: Don't play with console_loglevel

2019-05-27 Thread Sergey Senozhatsky

On (05/28/19 12:21), Tetsuo Handa wrote:
[..]
> What I suggested in my proposal ("printk: Introduce "store now but print 
> later" prefix." at
> https://lore.kernel.org/lkml/1550896930-12324-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp/T/#u
>  )
> is "whether the caller wants to defer printing to consoles regarding
> this printk() call". And your suggestion is "whether the caller wants
> to apply ignore_loglevel regarding this printk() call".

I'm not sure about "store now but print later" here. What Dmitry is
talking about:

 bump console_loglevel on *this* particular CPU only,
 not system-wide.
 /* Which is implemented in a form of - all messages from this-CPU
  * only should be printed regardless the loglevel, the rest should
  * pass the usual suppress_message_printing() check. */

-ss

Re: [PATCH 1/2] vfio: ABI for setting mdev display flip eventfd

2019-05-27 Thread Alex Williamson

On Tue, 28 May 2019 01:42:57 +
"Zhang, Tina"  wrote:

> > -Original Message-
> > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> > Behalf Of Alex Williamson
> > Sent: Monday, May 27, 2019 10:05 PM
> > To: Zhang, Tina 
> > Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > zhen...@linux.intel.com; Yuan, Hang ;
> > kra...@redhat.com; intel-gvt-...@lists.freedesktop.org; Lv, Zhiyuan
> > 
> > Subject: Re: [PATCH 1/2] vfio: ABI for setting mdev display flip eventfd
> > 
> > On Mon, 27 May 2019 16:43:11 +0800
> > Tina Zhang  wrote:
> >   
> > > Add VFIO_DEVICE_SET_GFX_FLIP_EVENTFD ioctl command to set eventfd
> > > based signaling mechanism to deliver vGPU framebuffer page flip event
> > > to userspace.
> > >
> > > Signed-off-by: Tina Zhang 
> > > ---
> > >  include/uapi/linux/vfio.h | 12 
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > index 02bb7ad6e986..27300597717f 100644
> > > --- a/include/uapi/linux/vfio.h
> > > +++ b/include/uapi/linux/vfio.h
> > > @@ -696,6 +696,18 @@ struct vfio_device_ioeventfd {
> > >
> > >  #define VFIO_DEVICE_IOEVENTFD_IO(VFIO_TYPE, VFIO_BASE +  
> > 16)  
> > >
> > > +/**
> > > + * VFIO_DEVICE_SET_GFX_FLIP_EVENTFD - _IOW(VFIO_TYPE, VFIO_BASE  
> > + 17,  
> > > +__s32)
> > > + *
> > > + * Set eventfd based signaling mechanism to deliver vGPU framebuffer
> > > +page
> > > + * flip event to userspace. A value of -1 is used to stop the page
> > > +flip
> > > + * delivering.
> > > + *
> > > + * Return: 0 on success, -errno on failure.
> > > + */
> > > +
> > > +#define VFIO_DEVICE_SET_GFX_FLIP_EVENTFD _IO(VFIO_TYPE,  
> > VFIO_BASE +  
> > > +17)
> > > +
> > >  /*  API for Type1 VFIO IOMMU  */
> > >
> > >  /**  
> > 
> > Why can't we use VFIO_DEVICE_SET_IRQS for this?  We can add a capability
> > to vfio_irq_info in the same way that we did for regions to describe device
> > specific IRQ support.  Thanks,  
> Add a new kind of index, like this?
> enum {
> VFIO_PCI_INTX_IRQ_INDEX,
> VFIO_PCI_MSI_IRQ_INDEX,
> VFIO_PCI_MSIX_IRQ_INDEX,
> VFIO_PCI_ERR_IRQ_INDEX,
> VFIO_PCI_REQ_IRQ_INDEX,
> +  VFIO_PCI_GFX_FLIP_EVENT_INDEX,
> VFIO_PCI_NUM_IRQS
> };
> Perhaps this is what we don't want. This
> VFIO_PCI_GFX_FLIP_EVENT_INDEX is specific to graphics card and it's
> actually an event which is reported by INTX/MSI/ MSIX IRQ. Thanks.

Right, that is not what I'm suggesting.  What I'm looking for is a
similar conversion to what we did for regions, where we extended the
data returned in GET_REGION_INFO to include capabilities
(c84982adb23b), capped the number of regions we define with fixed
indexes (c7bb4cb40f89), and added device specific regions, such as IGD
OpRegion (5846ff54e87d) and IGD host and LPC bridges (f572a960a15e).
The same thing should happen here, the current value of
VFIO_PCI_NUM_IRQS becomes fixed and part of the vfio-pci ABI,
vfio_irq_info is extended with capability support following the same
mechanism, headers, and helpers we use for regions, then the mdev device
simply exposes the extended (and backwards compatible) API without
requiring a device specific ioctl.  Thanks,

Alex

Re: [RFC] printk/sysrq: Don't play with console_loglevel

2019-05-27 Thread Sergey Senozhatsky

On (05/28/19 01:24), Dmitry Safonov wrote:
[..]
> While handling sysrq the console_loglevel is bumped to default to print
> sysrq headers. It's done to print sysrq messages with WARNING level for
> consumers of /proc/kmsg, though it sucks by the following reasons:
> - changing console_loglevel may produce tons of messages (especially on
>   bloated with debug/info prints systems)
> - it doesn't guarantee that the message will be printed as printk may
>   deffer the actual console output from buffer (see the comment near
>   printk() in kernel/printk/printk.c)
> 
> Provide KERN_UNSUPPRESSED printk() annotation for such legacy places.
> Make sysrq print the headers unsuppressed instead of changing
> console_loglevel.

I've been thinking about this a while ago... So what I thought back
then was that affected paths are atomic: sysrq, irqs, NMI, etc. Well
at leasted it seemed to be so. Hence we can use per-CPU flag to tell
printk that whatever comes from this-CPU is important and printk should
eventually print it (next time it hits console_unlock()). One candidate
for such per-CPU flag was this_cpu(printk_context). We can steal high
bit (next to NMI printk_safe bit). So the intended use case was something
like this

sysrq/etc  /* atomic context */
{
printk_blah_enter();

for (...)
printk();
...
dump_bar();

prinkt_blah_exit();
}

printk_blah_enter() would set that special - printk_safe_mask_blah - bit,
and prinkt_blah_exit() would clear it. Whenever prinkt->vprintk_store()
would see printk_safe_mask_blah bit set it would mark the log_stored message
as "important, always print!", and console_unlock() would always print those
"important" messages.

-ss

Re: [RESEND PATCH 0/3] Allow custom PCI resource alignment on pseries

On 5/27/19 11:01 PM, Oliver wrote:

On Tue, May 28, 2019 at 8:56 AM Shawn Anastasio wrote:

Hello all,

This patch set implements support for user-specified PCI resource
alignment on the pseries platform for hotplugged PCI devices.
Currently on pseries, PCI resource alignments specified with the
pci=resource_alignment commandline argument are ignored, since
the firmware is in charge of managing the PCI resources. In the
case of hotplugged devices, though, the kernel is in charge of
configuring the resources and should obey alignment requirements.

Are you using hotplug to work around SLOF (the OF we use under qemu)
not aligning BARs to 64K? It looks like there is a commit in SLOF to
fix that
(https://git.qemu.org/?p=SLOF.git;a=commit;f=board-qemu/slof/pci-phb.fs;h=1903174472f8800caf50c959b304501b4c01153c).

No, my application actually requires PCI hotplug at run-time.

The current behavior of ignoring the alignment for hotplugged devices
results in sub-page BARs landing between page boundaries and
becoming un-mappable from userspace via the VFIO framework.
This issue was observed on a pseries KVM guest with hotplugged
ivshmem devices.

With these changes, users can specify an appropriate
pci=resource_alignment argument on boot for devices they wish to use
with VFIO.

In the future, this could be extended to provide page-aligned
resources by default for hotplugged devices, similar to what is done
on powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned").

Can we make aligning the BARs to PAGE_SIZE the default behaviour? The
BAR assignment process is complex enough as-is so I'd rather we didn't
add another platform hack into the mix.

Absolutely. This will still require the existing changes so that the
custom alignment isn't flat-out ignored on pseries, but I can set

it to default to PAGE_SIZE as well, similar to how it's done on PowerNV.
I've just pushed a v3 to fix a typo and I'll incorporate this change
in v4.

Feedback is appreciated.

Thanks,
Shawn

Shawn Anastasio (3):
PCI: Introduce pcibios_ignore_alignment_request
powerpc/64: Enable pcibios_after_init hook on ppc64
powerpc/pseries: Allow user-specified PCI resource alignment after
init

--
2.20.1

[PATCH v3 3/3] powerpc/pseries: Allow user-specified PCI resource alignment after init

On pseries, custom PCI resource alignment specified with the commandline
argument pci=resource_alignment is disabled due to PCI resources being
managed by the firmware. However, in the case of PCI hotplug the
resources are managed by the kernel, so custom alignments should be
honored in these cases. This is done by only honoring custom
alignments after initial PCI initialization is done, to ensure that
all devices managed by the firmware are excluded.

Without this ability, sub-page BARs sometimes get mapped in between
page boundaries for hotplugged devices and are therefore unusable
with the VFIO framework. This change allows users to request
page alignment for devices they wish to access via VFIO using
the pci=resource_alignment commandline argument.

In the future, this could be extended to provide page-aligned
resources by default for hotplugged devices, similar to what is
done on powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned")

Signed-off-by: Shawn Anastasio 
---
 arch/powerpc/include/asm/machdep.h |  3 +++
 arch/powerpc/kernel/pci-common.c   |  9 +
 arch/powerpc/platforms/pseries/setup.c | 22 ++
 3 files changed, 34 insertions(+)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 2fbfaa9176ed..46eb62c0954e 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -179,6 +179,9 @@ struct machdep_calls {
 
resource_size_t (*pcibios_default_alignment)(void);
 
+   /* Called when determining PCI resource alignment */
+   int (*pcibios_ignore_alignment_request)(void);
+
 #ifdef CONFIG_PCI_IOV
void (*pcibios_fixup_sriov)(struct pci_dev *pdev);
resource_size_t (*pcibios_iov_resource_alignment)(struct pci_dev *, int 
resno);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index ff4b7539cbdf..8e0d73b4c188 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -238,6 +238,15 @@ resource_size_t pcibios_default_alignment(void)
return 0;
 }
 
+int pcibios_ignore_alignment_request(void)
+{
+   if (ppc_md.pcibios_ignore_alignment_request)
+   return ppc_md.pcibios_ignore_alignment_request();
+
+   /* Fall back to default method of checking PCI_PROBE_ONLY */
+   return pci_has_flag(PCI_PROBE_ONLY);
+}
+
 #ifdef CONFIG_PCI_IOV
 resource_size_t pcibios_iov_resource_alignment(struct pci_dev *pdev, int resno)
 {
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index e4f0dfd4ae33..07f03be02afe 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -82,6 +82,8 @@ EXPORT_SYMBOL(CMO_PageSize);
 
 int fwnmi_active;  /* TRUE if an FWNMI handler is present */
 
+static int initial_pci_init_done; /* TRUE if initial pcibios init has 
completed */
+
 static void pSeries_show_cpuinfo(struct seq_file *m)
 {
struct device_node *root;
@@ -749,6 +751,23 @@ static resource_size_t 
pseries_pci_iov_resource_alignment(struct pci_dev *pdev,
 }
 #endif
 
+static void pseries_after_init(void)
+{
+   initial_pci_init_done = 1;
+}
+
+static int pseries_ignore_alignment_request(void)
+{
+   if (initial_pci_init_done)
+   /*
+* Allow custom alignments after init for things
+* like PCI hotplugging.
+*/
+   return 0;
+
+   return pci_has_flag(PCI_PROBE_ONLY);
+}
+
 static void __init pSeries_setup_arch(void)
 {
set_arch_panic_timeout(10, ARCH_PANIC_TIMEOUT);
@@ -797,6 +816,9 @@ static void __init pSeries_setup_arch(void)
}
 
ppc_md.pcibios_root_bridge_prepare = pseries_root_bridge_prepare;
+   ppc_md.pcibios_after_init = pseries_after_init;
+   ppc_md.pcibios_ignore_alignment_request =
+   pseries_ignore_alignment_request;
 }
 
 static void pseries_panic(char *str)
-- 
2.20.1

[PATCH v3 0/3] Allow custom PCI resource alignment on pseries

Changes from v2 to v3:
  - Fix wrong return type of ppc pcibios_ignore_alignment_request
(Not sure how my local compile didn't catch that!)

Hello all,

This patch set implements support for user-specified PCI resource
alignment on the pseries platform for hotplugged PCI devices.
Currently on pseries, PCI resource alignments specified with the
pci=resource_alignment commandline argument are ignored, since
the firmware is in charge of managing the PCI resources. In the
case of hotplugged devices, though, the kernel is in charge of 
configuring the resources and should obey alignment requirements.

The current behavior of ignoring the alignment for hotplugged devices
results in sub-page BARs landing between page boundaries and
becoming un-mappable from userspace via the VFIO framework.
This issue was observed on a pseries KVM guest with hotplugged
ivshmem devices.
 
With these changes, users can specify an appropriate
pci=resource_alignment argument on boot for devices they wish to use 
with VFIO.

In the future, this could be extended to provide page-aligned
resources by default for hotplugged devices, similar to what is done
on powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned").

Feedback is appreciated.

Thanks,
Shawn

Shawn Anastasio (3):
  PCI: Introduce pcibios_ignore_alignment_request
  powerpc/64: Enable pcibios_after_init hook on ppc64
  powerpc/pseries: Allow user-specified PCI resource alignment after
init

 arch/powerpc/include/asm/machdep.h |  6 --
 arch/powerpc/kernel/pci-common.c   |  9 +
 arch/powerpc/kernel/pci_64.c   |  4 
 arch/powerpc/platforms/pseries/setup.c | 22 ++
 drivers/pci/pci.c  |  9 +++--
 include/linux/pci.h|  1 +
 6 files changed, 47 insertions(+), 4 deletions(-)

-- 
2.20.1

[PATCH v3 2/3] powerpc/64: Enable pcibios_after_init hook on ppc64

Enable the pcibios_after_init hook on all powerpc platforms.
This hook is executed at the end of pcibios_init and was previously
only available on CONFIG_PPC32.

Since it is useful and not inherently limited to 32-bit mode,
remove the limitation and allow it on all powerpc platforms.

Signed-off-by: Shawn Anastasio 
---
 arch/powerpc/include/asm/machdep.h | 3 +--
 arch/powerpc/kernel/pci_64.c   | 4 
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 2f0ca6560e47..2fbfaa9176ed 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -150,6 +150,7 @@ struct machdep_calls {
void(*init)(void);
 
void(*kgdb_map_scc)(void);
+#endif /* CONFIG_PPC32 */
 
/*
 * optional PCI "hooks"
@@ -157,8 +158,6 @@ struct machdep_calls {
/* Called at then very end of pcibios_init() */
void (*pcibios_after_init)(void);
 
-#endif /* CONFIG_PPC32 */
-
/* Called in indirect_* to avoid touching devices */
int (*pci_exclude_device)(struct pci_controller *, unsigned char, 
unsigned char);
 
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 9d8c10d55407..fba7fe6e4a50 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -68,6 +68,10 @@ static int __init pcibios_init(void)
 
printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
 
+   /* Call machine dependent post-init code */
+   if (ppc_md.pcibios_after_init)
+   ppc_md.pcibios_after_init();
+
return 0;
 }
 
-- 
2.20.1

[PATCH v3 1/3] PCI: Introduce pcibios_ignore_alignment_request

Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine whether or not to ignore alignment requests for PCI resources.

The existing behavior is to simply ignore alignment requests when
PCI_PROBE_ONLY is set. This is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.

Signed-off-by: Shawn Anastasio 
---
 drivers/pci/pci.c   | 9 +++--
 include/linux/pci.h | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8abc843b1615..8207a09085d1 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5882,6 +5882,11 @@ resource_size_t __weak pcibios_default_alignment(void)
return 0;
 }
 
+int __weak pcibios_ignore_alignment_request(void)
+{
+   return pci_has_flag(PCI_PROBE_ONLY);
+}
+
 #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
 static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
 static DEFINE_SPINLOCK(resource_alignment_lock);
@@ -5906,9 +5911,9 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
p = resource_alignment_param;
if (!*p && !align)
goto out;
-   if (pci_has_flag(PCI_PROBE_ONLY)) {
+   if (pcibios_ignore_alignment_request()) {
align = 0;
-   pr_info_once("PCI: Ignoring requested alignments 
(PCI_PROBE_ONLY)\n");
+   pr_info_once("PCI: Ignoring requested alignments\n");
goto out;
}
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4a5a84d7bdd4..47471dcdbaf9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1990,6 +1990,7 @@ static inline void pcibios_penalize_isa_irq(int irq, int 
active) {}
 int pcibios_alloc_irq(struct pci_dev *dev);
 void pcibios_free_irq(struct pci_dev *dev);
 resource_size_t pcibios_default_alignment(void);
+int pcibios_ignore_alignment_request(void);
 
 #ifdef CONFIG_HIBERNATE_CALLBACKS
 extern struct dev_pm_ops pcibios_pm_ops;
-- 
2.20.1

Re: [RESEND PATCH 0/3] Allow custom PCI resource alignment on pseries

2019-05-27 Thread Oliver

On Tue, May 28, 2019 at 8:56 AM Shawn Anastasio  wrote:
>
> Hello all,
>
> This patch set implements support for user-specified PCI resource
> alignment on the pseries platform for hotplugged PCI devices.
> Currently on pseries, PCI resource alignments specified with the
> pci=resource_alignment commandline argument are ignored, since
> the firmware is in charge of managing the PCI resources. In the
> case of hotplugged devices, though, the kernel is in charge of
> configuring the resources and should obey alignment requirements.

Are you using hotplug to work around SLOF (the OF we use under qemu)
not aligning BARs to 64K? It looks like there is a commit in SLOF to
fix that 
(https://git.qemu.org/?p=SLOF.git;a=commit;f=board-qemu/slof/pci-phb.fs;h=1903174472f8800caf50c959b304501b4c01153c).

> The current behavior of ignoring the alignment for hotplugged devices
> results in sub-page BARs landing between page boundaries and
> becoming un-mappable from userspace via the VFIO framework.
> This issue was observed on a pseries KVM guest with hotplugged
> ivshmem devices.

> With these changes, users can specify an appropriate
> pci=resource_alignment argument on boot for devices they wish to use
> with VFIO.
>
> In the future, this could be extended to provide page-aligned
> resources by default for hotplugged devices, similar to what is done
> on powernv by commit 382746376993 ("powerpc/powernv: Override
> pcibios_default_alignment() to force PCI devices to be page aligned").

Can we make aligning the BARs to PAGE_SIZE the default behaviour? The
BAR assignment process is complex enough as-is so I'd rather we didn't
add another platform hack into the mix.

> Feedback is appreciated.
>
> Thanks,
> Shawn
>
> Shawn Anastasio (3):
>   PCI: Introduce pcibios_ignore_alignment_request
>   powerpc/64: Enable pcibios_after_init hook on ppc64
>   powerpc/pseries: Allow user-specified PCI resource alignment after
> init
>
>  arch/powerpc/include/asm/machdep.h |  6 --
>  arch/powerpc/kernel/pci-common.c   |  9 +
>  arch/powerpc/kernel/pci_64.c   |  4 
>  arch/powerpc/platforms/pseries/setup.c | 22 ++
>  drivers/pci/pci.c  |  9 +++--
>  5 files changed, 46 insertions(+), 4 deletions(-)
>
> --
> 2.20.1
>

RE: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.

2019-05-27 Thread Anup Patel



> -Original Message-
> From: Troy Benjegerdes 
> Sent: Tuesday, May 28, 2019 5:11 AM
> To: Karsten Merker 
> Cc: Ard Biesheuvel ; Albert Ou
> ; Jonathan Corbet ; Anup Patel
> ; Zong Li ; Atish Patra
> ; Nick Kossifidis ; Palmer Dabbelt
> ; paul.walms...@sifive.com; linux-
> ri...@lists.infradead.org; marek.va...@gmail.com
> Subject: Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can
> parse.
> 
> 
> 
> > On May 27, 2019, at 5:16 PM, Karsten Merker 
> wrote:
> >
> > On Mon, May 27, 2019 at 04:34:57PM +0200, Ard Biesheuvel wrote:
> >> On Fri, 24 May 2019 at 06:18, Atish Patra  wrote:
> >>> Currently, the last stage boot loaders such as U-Boot can accept
> >>> only uImage which is an unnecessary additional step in automating
> >>> boot process.
> >>>
> >>> Add an image header that boot loader understands and boot Linux from
> >>> flat Image directly.
> >>>
> >>> This header is based on ARM64 boot image header and provides an
> >>> opportunity to combine both ARM64 & RISC-V image headers in future.
> >>>
> >>> Also make sure that PE/COFF header can co-exist in the same image so
> >>> that EFI stub can be supported for RISC-V in future. EFI
> >>> specification needs PE/COFF image header in the beginning of the
> >>> kernel image in order to load it as an EFI application. In order to
> >>> support EFI stub, code0 should be replaced with "MZ" magic string
> >>> and res4(at offset 0x3c) should point to the rest of the PE/COFF
> >>> header (which will be added during EFI support).
> > [...]
> >>> Documentation/riscv/boot-image-header.txt | 50
> ++
> >>> arch/riscv/include/asm/image.h| 64 +++
> >>> arch/riscv/kernel/head.S  | 32 
> >>> 3 files changed, 146 insertions(+)
> >>> create mode 100644 Documentation/riscv/boot-image-header.txt
> >>> create mode 100644 arch/riscv/include/asm/image.h
> >>>
> >>> diff --git a/Documentation/riscv/boot-image-header.txt
> >>> b/Documentation/riscv/boot-image-header.txt
> >>> new file mode 100644
> >>> index ..68abc2353cec
> >>> --- /dev/null
> >>> +++ b/Documentation/riscv/boot-image-header.txt
> >>> @@ -0,0 +1,50 @@
> >>> +   Boot image header in RISC-V Linux
> >>> +
> >>> + =
> >>> +
> >>> +Author: Atish Patra  Date  : 20 May 2019
> >>> +
> >>> +This document only describes the boot image header details for RISC-V
> Linux.
> >>> +The complete booting guide will be available at
> Documentation/riscv/booting.txt.
> >>> +
> >>> +The following 64-byte header is present in decompressed Linux kernel
> image.
> >>> +
> >>> +   u32 code0;/* Executable code */
> >>> +   u32 code1;/* Executable code */
> >>
> >> Apologies for not mentioning this in my previous reply, but given
> >> that you already know that you will need to put the magic string MZ
> >> at offset 0x0, it makes more sense to not put any code there at all,
> >> but educate the bootloader that the first executable instruction is
> >> at offset 0x20, and put the spare fields right after it in case you
> >> ever need more than 2 slots. (On arm64, we were lucky to be able to
> >> find an opcode that happened to contain the MZ bit pattern and act
> >> almost like a NOP, but it seems silly to rely on that for RISC-V as
> >> well)
> >>
> >> So something like
> >>
> >> u16 pe_res1;  /* MZ for EFI bootable images, don't care otherwise */
> >> u8 magic[6];/* "RISCV\0"
> >>
> >> u64 text_offset;  /* Image load offset, little endian */
> >> u64 image_size;   /* Effective Image size, little endian */
> >> u64 flags;/* kernel flags, little endian */
> >>
> >> u32 code0;/* Executable code */
> >> u32 code1;/* Executable code */
> >>
> >> u64 reserved[2]; /* reserved for future use */
> >>
> >> u32 version;  /* Version of this header */
> >> u32 pe_res2; /* Reserved for PE COFF offset */
> >
> > Hello,
> >
> > wouldn't that immediately break existing systems (including qemu when
> > loading kernels with the "-kernel" option) that rely on the fact that
> > the kernel entry point is always at the kernel load address?  The
> > ARM64 header and Atish's original RISC-V proposal based on the ARM64
> > header keep the property that jumping to the kernel load address
> > always works, regardless of what the particular header looks like and
> > which potential future extensions it includes, but the proposed change
> > above wouldn't do that.
> >
> > Although I agree that having to integrate the "MZ" string as an
> > instruction isn't particularly nice, I don't think that this is a
> > sufficient justification for breaking compatibility with prior kernel
> > releases and/or existing boot firmware.  On RISC-V, the "MZ" string is
> > a compressed load immediate to x20/s4, i.e. an instruction that should
> > be "harmless" as far as

linux-next: build failure after merge of the akpm-current tree

2019-05-27 Thread Stephen Rothwell

Hi all,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from arch/arm/mm/extable.c:6:
include/linux/uaccess.h:302:29: error: static declaration of 'probe_user_read' 
follows non-static declaration
 static __always_inline long probe_user_read(void *dst, const void __user *src,
 ^~~
include/linux/uaccess.h:254:13: note: previous declaration of 'probe_user_read' 
was here
 extern long probe_user_read(void *dst, const void __user *src, size_t size);
 ^~~

(and more ...)

Caused by commit

  3d127e17e970 ("include/linux/uaccess.h: add probe_user_read()")

interacting with commit

  3d7081822f7f ("uaccess: Add non-pagefault user-space read functions")

from the ftrace tree.

I have reverted the akpm-current tree fix for today (and the following
"mm-add-probe_user_read-fix").  Hopefully the following commit

  f414d1502add ("powerpc: use probe_user_read()") is still valid.

-- 
Cheers,
Stephen Rothwell


pgpA8zZMaMTC3.pgp
Description: OpenPGP digital signature

Re: [RFC 7/7] mm: madvise support MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER

2019-05-27 Thread Minchan Kim

On Mon, May 27, 2019 at 02:44:11PM +0200, Michal Hocko wrote:
> On Mon 27-05-19 16:58:11, Minchan Kim wrote:
> > On Tue, May 21, 2019 at 08:26:28AM +0200, Michal Hocko wrote:
> > > On Tue 21-05-19 11:55:33, Minchan Kim wrote:
> > > > On Mon, May 20, 2019 at 11:28:01AM +0200, Michal Hocko wrote:
> > > > > [cc linux-api]
> > > > > 
> > > > > On Mon 20-05-19 12:52:54, Minchan Kim wrote:
> > > > > > System could have much faster swap device like zRAM. In that case, 
> > > > > > swapping
> > > > > > is extremely cheaper than file-IO on the low-end storage.
> > > > > > In this configuration, userspace could handle different strategy 
> > > > > > for each
> > > > > > kinds of vma. IOW, they want to reclaim anonymous pages by MADV_COLD
> > > > > > while it keeps file-backed pages in inactive LRU by MADV_COOL 
> > > > > > because
> > > > > > file IO is more expensive in this case so want to keep them in 
> > > > > > memory
> > > > > > until memory pressure happens.
> > > > > > 
> > > > > > To support such strategy easier, this patch introduces
> > > > > > MADV_ANONYMOUS_FILTER and MADV_FILE_FILTER options in madvise(2) 
> > > > > > like
> > > > > > that /proc//clear_refs already has supported same filters.
> > > > > > They are filters could be Ored with other existing hints using top 
> > > > > > two bits
> > > > > > of (int behavior).
> > > > > 
> > > > > madvise operates on top of ranges and it is quite trivial to do the
> > > > > filtering from the userspace so why do we need any additional 
> > > > > filtering?
> > > > > 
> > > > > > Once either of them is set, the hint could affect only the 
> > > > > > interested vma
> > > > > > either anonymous or file-backed.
> > > > > > 
> > > > > > With that, user could call a process_madvise syscall simply with a 
> > > > > > entire
> > > > > > range(0x0 - 0x) but either of MADV_ANONYMOUS_FILTER 
> > > > > > and
> > > > > > MADV_FILE_FILTER so there is no need to call the syscall range by 
> > > > > > range.
> > > > > 
> > > > > OK, so here is the reason you want that. The immediate question is why
> > > > > cannot the monitor do the filtering from the userspace. Slightly more
> > > > > work, all right, but less of an API to expose and that itself is a
> > > > > strong argument against.
> > > > 
> > > > What I should do if we don't have such filter option is to enumerate 
> > > > all of
> > > > vma via /proc//maps and then parse every ranges and inode from 
> > > > string,
> > > > which would be painful for 2000+ vmas.
> > > 
> > > Painful is not an argument to add a new user API. If the existing API
> > > suits the purpose then it should be used. If it is not usable, we can
> > > think of a different way.
> > 
> > I measured 1568 vma parsing overhead of /proc//maps in ARM64 modern
> > mobile CPU. It takes 60ms and 185ms on big cores depending on cpu governor.
> > It's never trivial.
> 
> This is not the only option. Have you tried to simply use
> /proc//map_files interface? This will provide you with all the file
> backed mappings.

I compared maps vs. map_files with 3036 file-backed vma.
Test scenario is to dump all of vmas of the process and parse address
ranges.
For map_files, it's easy to parse each address range because directory name
itself is range. However, in case of maps, I need to parse each range
line by line so need to scan all of lines.

(maps cover additional non-file-backed vmas so nr_vma is a little bigger)

performance mode:
map_files: nr_vma 3036 usec 13387
maps : nr_vma 3078 usec 12923

powersave mode:

map_files: nr_vma 3036 usec 52614
maps : nr_vma 3078 usec 41089

map_files is slower than maps if we dump all of vmas. I guess directory
operation needs much more jobs(e.g., dentry lookup, instantiation)
compared to maps.

[net-next,v3 2/2] net: phy: sfp: enable i2c-bus detection on ACPI based systems

Lookup I2C adapter using the "i2c-bus" device property on ACPI based
systems similar to how it's done with DT.

An example DSD describing an SFP on an ACPI based system:

Device (SFP0)
{
Name (_HID, "PRP0001")
Name (_CRS, ResourceTemplate()
{
GpioIo(Exclusive, PullDefault, 0, 0, IoRestrictionNone,
   "\\_SB.PCI0.RP01.GPIO", 0, ResourceConsumer)
{ 0, 1, 2, 3, 4 }
})
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", "sff,sfp" },
Package () { "i2c-bus", \_SB.PCI0.RP01.I2C.MUX.CH0 },
Package () { "maximum-power-milliwatt", 1000 },
Package () { "tx-disable-gpios", Package () { ^SFP0, 0, 0, 1} },
Package () { "reset-gpio",   Package () { ^SFP0, 0, 1, 1} },
Package () { "mod-def0-gpios",   Package () { ^SFP0, 0, 2, 1} },
Package () { "tx-fault-gpios",   Package () { ^SFP0, 0, 3, 0} },
Package () { "los-gpios",Package () { ^SFP0, 0, 4, 1} },
},
})
}

Device (PHY0)
{
Name (_HID, "PRP0001")
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", "ethernet-phy-ieee802.3-c45" },
Package () { "sfp", \_SB.PCI0.RP01.SFP0 },
Package () { "managed", "in-band-status" },
Package () { "phy-mode", "sgmii" },
},
})
}

Signed-off-by: Ruslan Babayev 
Cc: xe-linux-exter...@cisco.com
---
 drivers/net/phy/sfp.c | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index d4635c2178d1..7a6c8df8899b 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1783,6 +1784,7 @@ static int sfp_probe(struct platform_device *pdev)
 {
const struct sff_data *sff;
struct sfp *sfp;
+   struct i2c_adapter *i2c = NULL;
bool poll = false;
int irq, err, i;
 
@@ -1801,7 +1803,6 @@ static int sfp_probe(struct platform_device *pdev)
if (pdev->dev.of_node) {
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *id;
-   struct i2c_adapter *i2c;
struct device_node *np;
 
id = of_match_node(sfp_of_match, node);
@@ -1818,14 +1819,30 @@ static int sfp_probe(struct platform_device *pdev)
 
i2c = of_find_i2c_adapter_by_node(np);
of_node_put(np);
-   if (!i2c)
-   return -EPROBE_DEFER;
-
-   err = sfp_i2c_configure(sfp, i2c);
-   if (err < 0) {
-   i2c_put_adapter(i2c);
-   return err;
+   } else if (ACPI_COMPANION(>dev)) {
+   struct acpi_device *adev = ACPI_COMPANION(>dev);
+   struct fwnode_handle *fw = acpi_fwnode_handle(adev);
+   struct fwnode_reference_args args;
+   struct acpi_handle *acpi_handle;
+   int ret;
+
+   ret = acpi_node_get_property_reference(fw, "i2c-bus", 0, );
+   if (ACPI_FAILURE(ret) || !is_acpi_device_node(args.fwnode)) {
+   dev_err(>dev, "missing 'i2c-bus' property\n");
+   return -ENODEV;
}
+
+   acpi_handle = ACPI_HANDLE_FWNODE(args.fwnode);
+   i2c = i2c_acpi_find_adapter_by_handle(acpi_handle);
+   }
+
+   if (!i2c)
+   return -EPROBE_DEFER;
+
+   err = sfp_i2c_configure(sfp, i2c);
+   if (err < 0) {
+   i2c_put_adapter(i2c);
+   return err;
}
 
for (i = 0; i < GPIO_MAX; i++)
-- 
2.19.2

Re: [RFC] printk/sysrq: Don't play with console_loglevel

2019-05-27 Thread Tetsuo Handa

On 2019/05/28 9:24, Dmitry Safonov wrote:
> Provide KERN_UNSUPPRESSED printk() annotation for such legacy places.
> Make sysrq print the headers unsuppressed instead of changing
> console_loglevel.

I think that kdb also wants to use KERN_UNSUPPRESSED for making sure
that messages are printed. But that user calls dump function which is
indirectly calling printk() many times. Thus, I think that we need a
way to explicitly pass "how the message should be treated" as a
function argument.

What I suggested in my proposal ("printk: Introduce "store now but print later" 
prefix." at
https://lore.kernel.org/lkml/1550896930-12324-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp/T/#u
 )
is "whether the caller wants to defer printing to consoles regarding
this printk() call". And your suggestion is "whether the caller wants
to apply ignore_loglevel regarding this printk() call".

[net-next,v3 0/2] Enable SFP on ACPI based systems

Changes:
v2: more descriptive commit body
v3: made 'i2c_acpi_find_adapter_by_handle' static inline

Ruslan Babayev (2):
  i2c: acpi: export i2c_acpi_find_adapter_by_handle
  net: phy: sfp: enable i2c-bus detection on ACPI based systems

 drivers/i2c/i2c-core-acpi.c |  3 ++-
 drivers/net/phy/sfp.c   | 33 +
 include/linux/i2c.h |  6 ++
 3 files changed, 33 insertions(+), 9 deletions(-)

-- 
2.19.2

Re: [PATCH v3 3/3] tests: add close_range() tests

Christian Brauner  writes:
> This adds basic tests for the new close_range() syscall.
> - test that no invalid flags can be passed
> - test that a range of file descriptors is correctly closed
> - test that a range of file descriptors is correctly closed if there there
>   are already closed file descriptors in the range
> - test that max_fd is correctly capped to the current fdtable maximum
>
> Signed-off-by: Christian Brauner 
> Cc: Arnd Bergmann 
> Cc: Jann Horn 
> Cc: David Howells 
> Cc: Dmitry V. Levin 
> Cc: Oleg Nesterov 
> Cc: Linus Torvalds 
> Cc: Florian Weimer 
> Cc: Shuah Khan 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kselft...@vger.kernel.org
> ---
> v1: unchanged
> v2:
> - Christian Brauner :
>   - verify that close_range() correctly closes a single file descriptor
> v3:
> - Christian Brauner :
>   - add missing Cc for Shuah
>   - add missing Cc for linux-kselftest

Sorry I replied to v2, but I think my comments still apply:

https://lore.kernel.org/lkml/8736kzqpdm@concordia.ellerman.id.au/

cheers

[net-next,v3 1/2] i2c: acpi: export i2c_acpi_find_adapter_by_handle

This allows drivers to lookup i2c adapters on ACPI based systems similar to
of_get_i2c_adapter_by_node() with DT based systems.

Signed-off-by: Ruslan Babayev 
Cc: xe-linux-exter...@cisco.com
---
 drivers/i2c/i2c-core-acpi.c | 3 ++-
 include/linux/i2c.h | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 272800692088..964687534754 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -337,7 +337,7 @@ static int i2c_acpi_find_match_device(struct device *dev, 
void *data)
return ACPI_COMPANION(dev) == data;
 }
 
-static struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle)
+struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle)
 {
struct device *dev;
 
@@ -345,6 +345,7 @@ static struct i2c_adapter 
*i2c_acpi_find_adapter_by_handle(acpi_handle handle)
  i2c_acpi_find_match_adapter);
return dev ? i2c_verify_adapter(dev) : NULL;
 }
+EXPORT_SYMBOL_GPL(i2c_acpi_find_adapter_by_handle);
 
 static struct i2c_client *i2c_acpi_find_client_by_adev(struct acpi_device 
*adev)
 {
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 1308126fc384..9808993f5fd5 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -21,6 +21,7 @@
 #include 
 #include/* for Host Notify IRQ */
 #include   /* for struct device_node */
+#include /* for acpi_handle */
 #include /* for swab16 */
 #include 
 
@@ -981,6 +982,7 @@ bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
 u32 i2c_acpi_find_bus_speed(struct device *dev);
 struct i2c_client *i2c_acpi_new_device(struct device *dev, int index,
   struct i2c_board_info *info);
+struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle);
 #else
 static inline bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
 struct acpi_resource_i2c_serialbus 
**i2c)
@@ -996,6 +998,10 @@ static inline struct i2c_client 
*i2c_acpi_new_device(struct device *dev,
 {
return NULL;
 }
+static inline struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle 
h)
+{
+   return NULL;
+}
 #endif /* CONFIG_ACPI */
 
 #endif /* _LINUX_I2C_H */
-- 
2.19.2

RE: [PATCH 25/44] tools headers UAPI: Sync drm/drm.h with the kernel

2019-05-27 Thread Zhou, David(ChunMing)

Which branch are you based? Seems all the structs are already synced except 
DRM_CAP_SYNCOBJ_TIMELINE.

-David

-Original Message-
From: Arnaldo Carvalho de Melo  
Sent: Tuesday, May 28, 2019 6:37 AM
To: Ingo Molnar ; Thomas Gleixner 
Cc: Jiri Olsa ; Namhyung Kim ; Clark 
Williams ; linux-kernel@vger.kernel.org; 
linux-perf-us...@vger.kernel.org; Arnaldo Carvalho de Melo ; 
Adrian Hunter ; Brendan Gregg 
; Koenig, Christian ; 
Zhou, David(ChunMing) ; Dave Airlie ; 
Lionel Landwerlin ; Luis Cláudio Gonçalves 

Subject: [PATCH 25/44] tools headers UAPI: Sync drm/drm.h with the kernel

From: Arnaldo Carvalho de Melo 

To pick up the changes in these csets:

  060cebb20cdb ("drm: introduce a capability flag for syncobj timeline support")
  50d1ebef79ef ("drm/syncobj: add timeline signal ioctl for syncobj v5")
  ea569910cbab ("drm/syncobj: add transition iotcls between binary and timeline 
v2")
  27b575a9aa2f ("drm/syncobj: add timeline payload query ioctl v6")
  01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
  783195ec1cad ("drm/syncobj: disable the timeline UAPI for now v2")
  48197bc564c7 ("drm: add syncobj timeline support v9")

Which automagically results in the following new ioctls being recognized by the 
'perf trace' ioctl cmd arg beautifier:

  $ tools/perf/trace/beauty/drm_ioctl.sh > /tmp/before
  $ cp include/uapi/drm/drm.h tools/include/uapi/drm/drm.h
  $ tools/perf/trace/beauty/drm_ioctl.sh > /tmp/after
  $ diff -u /tmp/before /tmp/after
  --- /tmp/before   2019-05-22 10:25:31.443151182 -0300
  +++ /tmp/after2019-05-22 10:25:46.449354819 -0300
  @@ -103,6 +103,10 @@
[0xC7] = "MODE_LIST_LESSEES",
[0xC8] = "MODE_GET_LEASE",
[0xC9] = "MODE_REVOKE_LEASE",
  + [0xCA] = "SYNCOBJ_TIMELINE_WAIT",
  + [0xCB] = "SYNCOBJ_QUERY",
  + [0xCC] = "SYNCOBJ_TRANSFER",
  + [0xCD] = "SYNCOBJ_TIMELINE_SIGNAL",
[DRM_COMMAND_BASE + 0x00] = "I915_INIT",
[DRM_COMMAND_BASE + 0x01] = "I915_FLUSH",
[DRM_COMMAND_BASE + 0x02] = "I915_FLIP",
$

I.e. the strace like raw_tracepoint:sys_enter handler in 'perf trace'
will get the cmd integer value and map it to the string.

At some point it should be possible to translate from string to integer and use 
to filter using expressions such as:

   # perf trace -e ioctl/cmd==DRM_IOCTL_SYNCOBJ*/

Or some more suitable syntax to express that only these ioctls when acting on 
DRM fds should be shown.

Cc: Adrian Hunter 
Cc: Brendan Gregg 
Cc: Christian König 
Cc: Chunming Zhou 
Cc: Dave Airlie 
Cc: Jiri Olsa 
Cc: Lionel Landwerlin 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-jrc9ogw33w4zgqc3pu7o1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/include/uapi/drm/drm.h | 37 
 1 file changed, 37 insertions(+)

diff --git a/tools/include/uapi/drm/drm.h b/tools/include/uapi/drm/drm.h index 
300f336633f2..661d73f9a919 100644
--- a/tools/include/uapi/drm/drm.h
+++ b/tools/include/uapi/drm/drm.h
@@ -649,6 +649,7 @@ struct drm_gem_open {
 #define DRM_CAP_PAGE_FLIP_TARGET   0x11
 #define DRM_CAP_CRTC_IN_VBLANK_EVENT   0x12
 #define DRM_CAP_SYNCOBJ0x13
+#define DRM_CAP_SYNCOBJ_TIMELINE   0x14
 
 /** DRM_IOCTL_GET_CAP ioctl argument type */  struct drm_get_cap { @@ -735,8 
+736,18 @@ struct drm_syncobj_handle {
__u32 pad;
 };
 
+struct drm_syncobj_transfer {
+   __u32 src_handle;
+   __u32 dst_handle;
+   __u64 src_point;
+   __u64 dst_point;
+   __u32 flags;
+   __u32 pad;
+};
+
 #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)  #define 
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time 
+point to become available */
 struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -747,12 +758,33 @@ struct drm_syncobj_wait {
__u32 pad;
 };
 
+struct drm_syncobj_timeline_wait {
+   __u64 handles;
+   /* wait on specific timeline point for every handles*/
+   __u64 points;
+   /* absolute timeout */
+   __s64 timeout_nsec;
+   __u32 count_handles;
+   __u32 flags;
+   __u32 first_signaled; /* only valid when not waiting all */
+   __u32 pad;
+};
+
+
 struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
 };
 
+struct drm_syncobj_timeline_array {
+   __u64 handles;
+   __u64 points;
+   __u32 count_handles;
+   __u32 pad;
+};
+
+
 /* Query current scanout sequence number */  struct drm_crtc_get_sequence {
__u32 crtc_id;  /* requested crtc_id */
@@ -909,6 +941,11 @@ extern "C" {
 #define DRM_IOCTL_MODE_GET_LEASE   DRM_IOWR(0xC8, struct 
drm_mode_get_lease)
 #define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct 
drm_mode_revoke_lease)
 
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct 
drm_syncobj_timeline_wait)

[PATCH V13 5/5] arm64: dts: imx: add i.MX8QXP thermal support

From: Anson Huang 

Add i.MX8QXP CPU thermal zone support.

Signed-off-by: Anson Huang 
---
No change, just rebase the patch to top of linux-next and below my patch:
https://patchwork.kernel.org/patch/10962185/
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 9f52da6..4448c65 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
interrupt-parent = <>;
@@ -162,6 +163,11 @@
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
+
+   tsens: thermal-sensor {
+   compatible = "fsl,imx8qxp-sc-thermal", 
"fsl,imx-sc-thermal";
+   #thermal-sensor-cells = <1>;
+   };
};
 
timer {
@@ -530,4 +536,35 @@
power-domains = < IMX_SC_R_GPIO_7>;
};
};
+
+   thermal_zones: thermal-zones {
+   cpu-thermal0 {
+   polling-delay-passive = <250>;
+   polling-delay = <2000>;
+   thermal-sensors = < IMX_SC_R_SYSTEM>;
+   trips {
+   cpu_alert0: trip0 {
+   temperature = <107000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+   cpu_crit0: trip1 {
+   temperature = <127000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device =
+   <_0 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   <_1 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   <_2 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   <_3 THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+
+   };
+   };
+   };
+   };
 };
-- 
2.7.4

[PATCH V13 3/5] thermal: imx_sc: add i.MX system controller thermal support

From: Anson Huang 

i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..

This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.

Signed-off-by: Anson Huang 
---
Changes since V12:
- remove the COMPILE_TEST dependency as it depends on SCU firmware;
- remove unnecessary argement of_phandle_args according to the new API 
change, no need it now.
---
 drivers/thermal/Kconfig  |  11 
 drivers/thermal/Makefile |   1 +
 drivers/thermal/imx_sc_thermal.c | 136 +++
 3 files changed, 148 insertions(+)
 create mode 100644 drivers/thermal/imx_sc_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9966364..454cbe5 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -233,6 +233,17 @@ config IMX_THERMAL
  cpufreq is used as the cooling device to throttle CPUs when the
  passive trip is crossed.
 
+config IMX_SC_THERMAL
+   tristate "Temperature sensor driver for NXP i.MX SoCs with System 
Controller"
+   depends on ARCH_MXC && IMX_SCU
+   depends on OF
+   help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
 config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 74a37c7..717a1ba 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DB8500_THERMAL)  += db8500_thermal.o
 obj-$(CONFIG_ARMADA_THERMAL)   += armada_thermal.o
 obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
 obj-$(CONFIG_IMX_THERMAL)  += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL)   += imx_sc_thermal.o
 obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
 obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
 obj-$(CONFIG_DA9062_THERMAL)   += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..75ab1e2
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP  13
+
+static struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+   struct thermal_zone_device *tzd;
+   u32 resource_id;
+};
+
+struct req_get_temp {
+   u16 resource_id;
+   u8 type;
+} __packed;
+
+struct resp_get_temp {
+   u16 celsius;
+   u8 tenths;
+} __packed;
+
+struct imx_sc_msg_misc_get_temp {
+   struct imx_sc_rpc_msg hdr;
+   union {
+   struct req_get_temp req;
+   struct resp_get_temp resp;
+   } data;
+};
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+   struct imx_sc_msg_misc_get_temp msg;
+   struct imx_sc_rpc_msg *hdr = 
+   struct imx_sc_sensor *sensor = data;
+   int ret;
+
+   msg.data.req.resource_id = sensor->resource_id;
+   msg.data.req.type = IMX_SC_C_TEMP;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_MISC;
+   hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+   hdr->size = 2;
+
+   ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
+   if (ret) {
+   dev_err(>tzd->device, "read temp sensor %d failed, ret 
%d\n",
+   sensor->resource_id, ret);
+   return ret;
+   }
+
+   *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
+
+   return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+   .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_probe(struct platform_device *pdev)
+{
+   struct device_node *np, *child;
+   struct imx_sc_sensor *sensor;
+   int ret;
+
+   ret = imx_scu_get_handle(_ipc_handle);
+   if (ret)
+   return ret;
+
+   np = of_find_node_by_name(NULL, "thermal-zones");
+   if (!np)
+   return -ENODEV;
+
+   for_each_available_child_of_node(np, child) {
+   sensor = devm_kzalloc(>dev, sizeof(*sensor), GFP_KERNEL);
+   if (!sensor)
+   return -ENOMEM;
+
+   ret =

[PATCH V13 1/5] dt-bindings: fsl: scu: add thermal binding

From: Anson Huang 

NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.

Signed-off-by: Anson Huang 
Reviewed-by: Rob Herring 
---
No change, just rebase the patch to top of linux-next and based on my watchdog 
patch:
https://patchwork.kernel.org/patch/10962183/
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt| 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index a575e42..fc3844e 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -155,6 +155,17 @@ Required properties:
 Optional properties:
 - timeout-sec: contains the watchdog timeout in seconds.
 
+Thermal bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible:  Should be :
+ "fsl,imx8qxp-sc-thermal"
+   followed by "fsl,imx-sc-thermal";
+
+- #thermal-sensor-cells:   See 
Documentation/devicetree/bindings/thermal/thermal.txt
+   for a description.
+
 Example (imx8qxp):
 -
 aliases {
@@ -222,6 +233,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
+
+   tsens: thermal-sensor {
+   compatible = "fsl,imx8qxp-sc-thermal", 
"fsl,imx-sc-thermal";
+   #thermal-sensor-cells = <1>;
+   };
};
 };
 
-- 
2.7.4

[PATCH V13 4/5] defconfig: arm64: add i.MX system controller thermal support

From: Anson Huang 

This patch enables CONFIG_IMX_SC_THERMAL as module.

Signed-off-by: Anson Huang 
---
No change, just rebase the patch to top of linux-next and based on below my 
patch:
https://patchwork.kernel.org/patch/10959025/
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index fa1ea8f..c33bf882 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -422,6 +422,7 @@ CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
 CONFIG_CPU_THERMAL=y
 CONFIG_THERMAL_EMULATION=y
 CONFIG_QORIQ_THERMAL=m
+CONFIG_IMX_SC_THERMAL=m
 CONFIG_ROCKCHIP_THERMAL=m
 CONFIG_RCAR_THERMAL=y
 CONFIG_RCAR_GEN3_THERMAL=y
-- 
2.7.4

[PATCH V13 2/5] thermal: of-thermal: add API for getting sensor ID from DT

From: Anson Huang 

On some platforms like i.MX8QXP, the thermal driver needs a
real HW sensor ID from DT thermal zone, the HW sensor ID is
used to get temperature from SCU firmware, and the virtual
sensor ID starting from 0 to N is NOT used at all, this patch
adds new API thermal_zone_of_get_sensor_id() to provide the
feature of getting sensor ID from DT thermal zone's node.

Signed-off-by: Anson Huang 
---
Changes since V12:
- allow the caller of thermal_zone_of_get_sensor_id() to pass NULL as 
second parameter
  of_phandle_args structure, as some caller maybe ONLY need to read 
sensor ID.
---
 drivers/thermal/of-thermal.c | 59 +++-
 include/linux/thermal.h  | 10 
 2 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index dc5093b..0466ab5 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -449,6 +449,52 @@ thermal_zone_of_add_sensor(struct device_node *zone,
 }
 
 /**
+ * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal zone
+ * @tz_np: a valid thermal zone device node.
+ * @sensor_specs: pointer to output arguments structure will be passed back,
+ *   it can be NULL if the caller does NOT need the output
+ *   arguments structure to be passed back.
+ * @id: a sensor ID pointer will be passed back.
+ *
+ * This function will get sensor ID from a given thermal zone node, use
+ * "thermal-sensors" as list name, and get sensor ID from first phandle's
+ * argument.
+ *
+ * Return: 0 on success, proper error code otherwise.
+ */
+
+int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
+ struct of_phandle_args *sensor_specs,
+ u32 *id)
+{
+   struct of_phandle_args tmp_sensor_specs;
+   int ret;
+
+   if (!sensor_specs)
+   sensor_specs = _sensor_specs;
+
+   ret = of_parse_phandle_with_args(tz_np,
+"thermal-sensors",
+"#thermal-sensor-cells",
+0,
+sensor_specs);
+   if (ret)
+   return ret;
+
+   if (sensor_specs->args_count >= 1) {
+   *id = sensor_specs->args[0];
+   WARN(sensor_specs->args_count > 1,
+"%pOFn: too many cells in sensor specifier %d\n",
+sensor_specs->np, sensor_specs->args_count);
+   } else {
+   *id = 0;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_get_sensor_id);
+
+/**
  * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
  * @dev: a valid struct device pointer of a sensor device. Must contain
  *   a valid .of_node, for the sensor node.
@@ -503,21 +549,10 @@ thermal_zone_of_sensor_register(struct device *dev, int 
sensor_id, void *data,
int ret, id;
 
/* For now, thermal framework supports only 1 sensor per zone */
-   ret = of_parse_phandle_with_args(child, "thermal-sensors",
-"#thermal-sensor-cells",
-0, _specs);
+   ret = thermal_zone_of_get_sensor_id(child, _specs, );
if (ret)
continue;
 
-   if (sensor_specs.args_count >= 1) {
-   id = sensor_specs.args[0];
-   WARN(sensor_specs.args_count > 1,
-"%pOFn: too many cells in sensor specifier %d\n",
-sensor_specs.np, sensor_specs.args_count);
-   } else {
-   id = 0;
-   }
-
if (sensor_specs.np == sensor_np && id == sensor_id) {
tzd = thermal_zone_of_add_sensor(child, sensor_np,
 data, ops);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 15a4ca5..c994e3a 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -375,6 +375,9 @@ struct thermal_trip {
 
 /* Function declarations */
 #ifdef CONFIG_THERMAL_OF
+int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
+ struct of_phandle_args *sensor_specs,
+ u32 *id);
 struct thermal_zone_device *
 thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
const struct thermal_zone_of_device_ops *ops);
@@ -386,6 +389,13 @@ struct thermal_zone_device 
*devm_thermal_zone_of_sensor_register(
 void devm_thermal_zone_of_sensor_unregister(struct device *dev,
struct thermal_zone_device *tz);
 #else
+
+static int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
+

[PATCH v2] platform/x86: intel_pmc_core: transform Pkg C-state residency from TSC ticks into microseconds

2019-05-27 Thread Harry Pan

Refer to the Intel SDM Vol.4, the package C-state residency counters
of modern IA micro-architecture are all ticking in TSC frequency,
hence we can apply simple math to transform the ticks into microseconds.
i.e.,
residency (ms) = count / tsc_khz
residency (us) = count / tsc_khz * 1000

This also aligns to other sysfs debug entries of residency counter in
the same metric in microseconds, benefits reading and scripting.

v2: restore the accidentally deleted newline, no function change.

Signed-off-by: Harry Pan 

---

 drivers/platform/x86/intel_pmc_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index f2c621b55f49..c78918a7e731 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "intel_pmc_core.h"
 
@@ -738,8 +739,8 @@ static int pmc_core_pkgc_show(struct seq_file *s, void 
*unused)
if (rdmsrl_safe(map[index].bit_mask, _count))
continue;
 
-   seq_printf(s, "%-8s : 0x%llx\n", map[index].name,
-  pcstate_count);
+   seq_printf(s, "%-8s : %llu\n", map[index].name,
+  pcstate_count * 1000 / tsc_khz);
}
 
return 0;
-- 
2.20.1

[PATCH] platform/x86: intel_pmc_core: transform Pkg C-state residency from TSC ticks into microseconds

2019-05-27 Thread Harry Pan

Refer to the Intel SDM Vol.4, the package C-state residency counters
of modern IA micro-architecture are all ticking in TSC frequency,
hence we can apply simple math to transform the ticks into microseconds.
i.e.,
residency (ms) = count / tsc_khz
residency (us) = count / tsc_khz * 1000

This also aligns to other sysfs debug entries of residency counter in
the same metric in microseconds, benefits reading and scripting.

v2: restore the accidentally deleted newline, no function change.

Signed-off-by: Harry Pan 

---

 drivers/platform/x86/intel_pmc_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index f2c621b55f49..c78918a7e731 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "intel_pmc_core.h"
 
@@ -738,8 +739,8 @@ static int pmc_core_pkgc_show(struct seq_file *s, void 
*unused)
if (rdmsrl_safe(map[index].bit_mask, _count))
continue;
 
-   seq_printf(s, "%-8s : 0x%llx\n", map[index].name,
-  pcstate_count);
+   seq_printf(s, "%-8s : %llu\n", map[index].name,
+  pcstate_count * 1000 / tsc_khz);
}
 
return 0;
-- 
2.20.1

MIPS r4k cache operations with SMP enabled

2019-05-27 Thread Chris Packham

Hi,

I'm trying to port a fairly old Broadcom integrated chip (BCM6818) to 
the latest Linux kernel using the mips/bmips support.

The chip has a BMIPS4355 core. This has two "thread processors" (cpu 
cores) with separate I-caches but a shared D-cache.

I've got things booting but I encounter the following BUG()

BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is blast_dcache16+0x24/0x154
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-at1 #5
Stack : 0036 8008d0d0 806a 807c 80754e10 000b 80754684 
8f831c8c
 8090 8f828424 807986e7 8071348c  10008f00 8f831c30 
7fb69e2a
   8092 0056 2335  807a 

 6d6d3a20  0056 73776170   10008f01 
807c
 8079 2cc2  8090 0010 8f83198c  
8090
 ...
Call Trace:
[<8001c208>] show_stack+0x30/0x100
[<8063282c>] dump_stack+0x9c/0xd0
[<802f1cec>] debug_smp_processor_id+0xfc/0x110
[<8002e274>] blast_dcache16+0x24/0x154
[<80122978>] map_vm_area+0x58/0x70
[<80123888>] __vmalloc_node_range+0x1fc/0x2b4
[<80123b54>] vmalloc+0x44/0x50
[<807d15d0>] jffs2_zlib_init+0x24/0x94
[<807d1354>] jffs2_compressors_init+0x10/0x30
[<807d151c>] init_jffs2_fs+0x68/0xf8
[<8001016c>] do_one_initcall+0x7c/0x1f0
[<807bee30>] kernel_init_freeable+0x17c/0x258
[<80650d1c>] kernel_init+0x10/0xf8
[<80015e6c>] ret_from_kernel_thread+0x14/0x1c

In blast_dcache16 current_cpu_data is used which invokes 
smp_processor_id() triggering the BUG(). I can fix this by sprinkling 
preempt_disable/preempt_enable through arch/mips/mm/c-r4k.c but that 
seems kind of wrong. Does anyone have any suggestion as to the right way 
to avoid this BUG()?

Thanks,
Chris

Re: [PATCH 1/2] vfio: ABI for setting mdev display flip eventfd

2019-05-27 Thread Zhenyu Wang

On 2019.05.27 14:22:37 +0200, Gerd Hoffmann wrote:
> On Mon, May 27, 2019 at 05:07:41PM +0800, Zhenyu Wang wrote:
> > On 2019.05.27 16:43:11 +0800, Tina Zhang wrote:
> > > Add VFIO_DEVICE_SET_GFX_FLIP_EVENTFD ioctl command to set eventfd
> > > based signaling mechanism to deliver vGPU framebuffer page flip
> > > event to userspace.
> > 
> > Should we add probe to see if driver can support gfx flip event?
> 
> Userspace can simply call VFIO_DEVICE_SET_GFX_FLIP_EVENTFD and see if it
> worked.  If so -> use the eventfd.  Otherwise take the fallback path
> (timer based polling).  I can't see any advantage a separate feature
> probe steps adds.
> 

Then we need to define error return which means driver doesn't support
e.g -ENOTTY, and driver shouldn't return that for other possible
failure, so user space won't get confused.

I think if we can define this as generic display event notification?
Not necessarily just for flip, just a display change notification to
let user space query current state.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

signature.asc
Description: PGP signature

[PATCH v2] arm64: dts: ls1028a: Add temperature sensor node

2019-05-27 Thread Yuantian Tang

Add nxp sa56004 chip node for temperature monitor.

Signed-off-by: Yuantian Tang 
---
v2:
- change the node name and add vcc-supply

 arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 15 +++
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 15 +++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index 6571d0483c7a..f12e4f510d6e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -47,6 +47,15 @@
regulator-always-on;
};
 
+   sb_3v3: regulator-sb3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "3v3_vbus";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "i2s";
@@ -147,6 +156,12 @@
compatible = "atmel,24c512";
reg = <0x57>;
};
+
+   temperature-sensor@4c {
+   compatible = "nxp,sa56004";
+   reg = <0x4c>;
+   vcc-supply = <_3v3>;
+   };
};
 
i2c@5 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 235ca3a83dc3..e64c28983ec9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -43,6 +43,15 @@
regulator-always-on;
};
 
+   sb_3v3: regulator-sb3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "3v3_vbus";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "i2s";
@@ -132,6 +141,12 @@
compatible = "nxp,pcf2129";
reg = <0x51>;
};
+
+   temperature-sensor@4c {
+   compatible = "nxp,sa56004";
+   reg = <0x4c>;
+   vcc-supply = <_3v3>;
+   };
};
};
 };
-- 
2.17.1

Re: [PATCH] ia64: fix build errors by exporting paddr_to_nid()

2019-05-27 Thread Randy Dunlap

ping...

On 5/3/19 9:42 PM, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix build errors on ia64 when DISCONTIGMEM=y and NUMA=y by
> exporting paddr_to_nid().
> 
> Fixes these build errors:
> 
> ERROR: "paddr_to_nid" [sound/core/snd-pcm.ko] undefined!
> ERROR: "paddr_to_nid" [net/sunrpc/sunrpc.ko] undefined!
> ERROR: "paddr_to_nid" [fs/cifs/cifs.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/video/fbdev/core/fb.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/usb/mon/usbmon.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/usb/core/usbcore.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/md/raid1.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/md/dm-mod.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/md/dm-crypt.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/md/dm-bufio.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/ide/ide-core.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/ide/ide-cd_mod.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/char/agp/agpgart.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/block/nbd.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/block/loop.ko] undefined!
> ERROR: "paddr_to_nid" [drivers/block/brd.ko] undefined!
> ERROR: "paddr_to_nid" [crypto/ccm.ko] undefined!
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Randy Dunlap 
> Cc: Tony Luck 
> Cc: Fenghua Yu 
> Cc: linux-i...@vger.kernel.org
> ---
>  arch/ia64/mm/numa.c |1 +
>  1 file changed, 1 insertion(+)
> 
> --- lnx-51-rc7.orig/arch/ia64/mm/numa.c
> +++ lnx-51-rc7/arch/ia64/mm/numa.c
> @@ -55,6 +55,7 @@ paddr_to_nid(unsigned long paddr)
>  
>   return (i < num_node_memblks) ? node_memblk[i].nid : (num_node_memblks 
> ? -1 : 0);
>  }
> +EXPORT_SYMBOL(paddr_to_nid);
>  
>  #if defined(CONFIG_SPARSEMEM) && defined(CONFIG_NUMA)
>  /*
> 
> 


-- 
~Randy

Re: [PATCH net-next v2 1/2] i2c: acpi: export i2c_acpi_find_adapter_by_handle



Mika Westerberg writes:

> On Fri, May 24, 2019 at 05:53:01PM -0700, Ruslan Babayev wrote:
>> +struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle);
>>  #else
>>  static inline bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
>>   struct acpi_resource_i2c_serialbus 
>> **i2c)
>> @@ -996,6 +998,10 @@ static inline struct i2c_client 
>> *i2c_acpi_new_device(struct device *dev,
>>  {
>>  return NULL;
>>  }
>> +struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle)
>
> This should be static inline, I think.
>
>> +{
>> +return NULL;
>> +}
>>  #endif /* CONFIG_ACPI */
>>  
>>  #endif /* _LINUX_I2C_H */
>> -- 
>> 2.17.1

Thanks Mika, will make the change and repost the patches.

[PATCH] clk-sunxi: fix a missing-check bug in sunxi_divs_clk_setup()

2019-05-27 Thread Gen Zhang

In sunxi_divs_clk_setup(), 'derived_name' is allocated by kstrndup().
It returns NULL when fails. 'derived_name' should be checked.

Signed-off-by: Gen Zhang 
---
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index f5b1c00..830bfb7 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -989,6 +989,8 @@ static struct clk ** __init sunxi_divs_clk_setup(struct 
device_node *node,
if (endp) {
derived_name = kstrndup(clk_name, endp - clk_name,
GFP_KERNEL);
+   if (!derived_name)
+   return NULL;
factors.name = derived_name;
} else {
factors.name = clk_name;
---

[PATCH v4 1/2] drivers: base: cacheinfo: Add variable to record max cache line size

2019-05-27 Thread Shaokun Zhang

Add coherency_max_size variable to record the maximum cache line size
for different cache levels. If it is available, we will synchronize
it as cache line size, otherwise we will use CTR_EL0.CWG reporting
in cache_line_size() for arm64.

Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Cc: Sudeep Holla 
Cc: Catalin Marinas 
Cc: Jeremy Linton 
Cc: Will Deacon 
Signed-off-by: Shaokun Zhang 
---
ChangeLog since v3:
  -- Address Greg's comments
  -- Fix some commit information

ChangeLog since v2:
  -- Rebase to 5.2-rc2
  -- Export cache_line_size for I/O driver

ChangeLog since v1:
  -- Move coherency_max_size to drivers/base/cacheinfo.c
  -- Address Catalin's comments
  Link: https://www.spinics.net/lists/arm-kernel/msg723615.html

 drivers/base/cacheinfo.c  | 5 +
 include/linux/cacheinfo.h | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index a7359535caf5..8827c60f51e2 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -213,6 +213,8 @@ int __weak cache_setup_acpi(unsigned int cpu)
return -ENOTSUPP;
 }
 
+unsigned int coherency_max_size;
+
 static int cache_shared_cpu_map_setup(unsigned int cpu)
 {
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
@@ -251,6 +253,9 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
cpumask_set_cpu(i, _leaf->shared_cpu_map);
}
}
+   /* record the maximum cache line size */
+   if (this_leaf->coherency_line_size > coherency_max_size)
+   coherency_max_size = this_leaf->coherency_line_size;
}
 
return 0;
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 70e19bc6cc9f..46b92cd61d0c 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -17,6 +17,8 @@ enum cache_type {
CACHE_TYPE_UNIFIED = BIT(2),
 };
 
+extern unsigned int coherency_max_size;
+
 /**
  * struct cacheinfo - represent a cache leaf node
  * @id: This cache's id. It is unique among caches with the same (type, level).
-- 
2.7.4

[PATCH v4 2/2] arm64: cacheinfo: Update cache_line_size detected from DT or PPTT

2019-05-27 Thread Shaokun Zhang

cache_line_size is derived from CTR_EL0.CWG field and is called mostly
for I/O device drivers. For HiSilicon certain plantform, like the
Kunpeng920 server SoC, cache line sizes are different between L1/2
cache and L3 cache while L1 cache line size is 64-byte and L3 is 128-byte,
but CTR_EL0.CWG is misreporting using L1 cache line size.

We shall correct the right value which is important for I/O performance.
Let's update the cache line size if it is detected from DT or PPTT
information.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Sudeep Holla 
Cc: Jeremy Linton 
Cc: Zhenfa Qiu 
Reported-by: Zhenfa Qiu 
Suggested-by: Catalin Marinas 
Signed-off-by: Shaokun Zhang 
---
 arch/arm64/include/asm/cache.h |  6 +-
 arch/arm64/kernel/cacheinfo.c  | 11 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 926434f413fa..758af6340314 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -91,11 +91,7 @@ static inline u32 cache_type_cwg(void)
 
 #define __read_mostly __attribute__((__section__(".data..read_mostly")))
 
-static inline int cache_line_size(void)
-{
-   u32 cwg = cache_type_cwg();
-   return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
-}
+int cache_line_size(void);
 
 /*
  * Read the effective value of CTR_EL0.
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 0bf0a835122f..0c0cd4d26b87 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -28,6 +28,17 @@
 #define CLIDR_CTYPE(clidr, level)  \
(((clidr) & CLIDR_CTYPE_MASK(level)) >> CLIDR_CTYPE_SHIFT(level))
 
+int cache_line_size(void)
+{
+   u32 cwg = cache_type_cwg();
+
+   if (coherency_max_size != 0)
+   return coherency_max_size;
+
+   return cwg ? 4 << cwg : ARCH_DMA_MINALIGN;
+}
+EXPORT_SYMBOL_GPL(cache_line_size);
+
 static inline enum cache_type get_cache_type(int level)
 {
u64 clidr;
-- 
2.7.4

Re: [PATCH] userfaultfd: selftest: fix compiler warning

2019-05-27 Thread Peter Xu

On Mon, May 27, 2019 at 03:18:59PM +, Alakesh Haloi wrote:
> Fixes following compiler warning
> 
> userfaultfd.c: In function ‘usage’:
> userfaultfd.c:126:2: warning: format not a string literal and no format
>   arguments [-Wformat-security]
>   fprintf(stderr, examples);
> 
> Signed-off-by: Alakesh Haloi 

Reviewed-by: Peter Xu 

-- 
Peter Xu

[PATCH RESEND v2] KVM: X86: Implement PV sched yield hypercall

2019-05-27 Thread Wanpeng Li

From: Wanpeng Li 

The target vCPUs are in runnable state after vcpu_kick and suitable 
as a yield target. This patch implements the sched yield hypercall.

17% performance increase of ebizzy benchmark can be observed in an 
over-subscribe environment. (w/ kvm-pv-tlb disabled, testing TLB flush 
call-function IPI-many since call-function is not easy to be trigged 
by userspace workload).

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/x86.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e7e57de..2f9ec08 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7172,6 +7172,28 @@ void kvm_vcpu_deactivate_apicv(struct kvm_vcpu *vcpu)
kvm_x86_ops->refresh_apicv_exec_ctrl(vcpu);
 }
 
+void kvm_sched_yield(struct kvm *kvm, u64 dest_id)
+{
+   struct kvm_vcpu *target;
+   struct kvm_apic_map *map;
+
+   rcu_read_lock();
+   map = rcu_dereference(kvm->arch.apic_map);
+
+   if (unlikely(!map))
+   goto out;
+
+   if (map->phys_map[dest_id]->vcpu) {
+   target = map->phys_map[dest_id]->vcpu;
+   rcu_read_unlock();
+   kvm_vcpu_yield_to(target);
+   }
+
+out:
+   if (!target)
+   rcu_read_unlock();
+}
+
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 {
unsigned long nr, a0, a1, a2, a3, ret;
@@ -7218,6 +7240,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
case KVM_HC_SEND_IPI:
ret = kvm_pv_send_ipi(vcpu->kvm, a0, a1, a2, a3, op_64_bit);
break;
+   case KVM_HC_SCHED_YIELD:
+   kvm_sched_yield(vcpu->kvm, a0);
+   ret = 0;
+   break;
default:
ret = -KVM_ENOSYS;
break;
-- 
2.7.4

Re: [PATCH -next v2] staging: kpc2000: Remove set but not used variable ‘status’

2019-05-27 Thread maowenan

please ignore v2 version.
I will send v3 later according to Sven Van Asbroeck 's comments.

On 2019/5/25 16:13, Mao Wenan wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/staging/kpc2000/kpc_spi/spi_driver.c: In function
> ‘kp_spi_transfer_one_message’:
> drivers/staging/kpc2000/kpc_spi/spi_driver.c:282:9: warning: variable
> ‘status’ set but not used [-Wunused-but-set-variable]
>  int status = 0;
>  ^~
> The variable 'status' is not used any more, remve it.
> 
> Signed-off-by: Mao Wenan 
> ---
>  v2: change the subject of the patch.
> ---
>  drivers/staging/kpc2000/kpc_spi/spi_driver.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/staging/kpc2000/kpc_spi/spi_driver.c 
> b/drivers/staging/kpc2000/kpc_spi/spi_driver.c
> index 86df16547a92..16f9518f8d63 100644
> --- a/drivers/staging/kpc2000/kpc_spi/spi_driver.c
> +++ b/drivers/staging/kpc2000/kpc_spi/spi_driver.c
> @@ -279,7 +279,6 @@ kp_spi_transfer_one_message(struct spi_master *master, 
> struct spi_message *m)
>  struct kp_spi   *kpspi;
>  struct spi_transfer *transfer;
>  union kp_spi_config sc;
> -int status = 0;
>  
>  spidev = m->spi;
>  kpspi = spi_master_get_devdata(master);
> @@ -332,7 +331,6 @@ kp_spi_transfer_one_message(struct spi_master *master, 
> struct spi_message *m)
>  /* do the transfers for this message */
>  list_for_each_entry(transfer, >transfers, transfer_list) {
>  if (transfer->tx_buf == NULL && transfer->rx_buf == NULL && 
> transfer->len) {
> -status = -EINVAL;
>  break;
>  }
>  
> @@ -370,7 +368,6 @@ kp_spi_transfer_one_message(struct spi_master *master, 
> struct spi_message *m)
>  m->actual_length += count;
>  
>  if (count != transfer->len) {
> -status = -EIO;
>  break;
>  }
>  }
>

[PATCH net] Documentation: net-sysfs: Remove duplicate PHY device documentation

2019-05-27 Thread Florian Fainelli

Both sysfs-bus-mdio and sysfs-class-net-phydev contain the same
duplication information. There is not currently any MDIO bus specific
attribute, but there are PHY device (struct phy_device) specific
attributes. Use the more precise description from sysfs-bus-mdio and
carry that over to sysfs-class-net-phydev.

Fixes: 86f22d04dfb5 ("net: sysfs: Document PHY device sysfs attributes")
Signed-off-by: Florian Fainelli 
---
 Documentation/ABI/testing/sysfs-bus-mdio  | 29 ---
 .../ABI/testing/sysfs-class-net-phydev| 19 
 2 files changed, 13 insertions(+), 35 deletions(-)
 delete mode 100644 Documentation/ABI/testing/sysfs-bus-mdio

diff --git a/Documentation/ABI/testing/sysfs-bus-mdio 
b/Documentation/ABI/testing/sysfs-bus-mdio
deleted file mode 100644
index 491baaf4285f..
--- a/Documentation/ABI/testing/sysfs-bus-mdio
+++ /dev/null
@@ -1,29 +0,0 @@
-What:  /sys/bus/mdio_bus/devices/.../phy_id
-Date:  November 2012
-KernelVersion: 3.8
-Contact:   net...@vger.kernel.org
-Description:
-   This attribute contains the 32-bit PHY Identifier as reported
-   by the device during bus enumeration, encoded in hexadecimal.
-   This ID is used to match the device with the appropriate
-   driver.
-
-What:  /sys/bus/mdio_bus/devices/.../phy_interface
-Date:  February 2014
-KernelVersion: 3.15
-Contact:   net...@vger.kernel.org
-Description:
-   This attribute contains the PHY interface as configured by the
-   Ethernet driver during bus enumeration, encoded in string.
-   This interface mode is used to configure the Ethernet MAC with 
the
-   appropriate mode for its data lines to the PHY hardware.
-
-What:  /sys/bus/mdio_bus/devices/.../phy_has_fixups
-Date:  February 2014
-KernelVersion: 3.15
-Contact:   net...@vger.kernel.org
-Description:
-   This attribute contains the boolean value whether a given PHY
-   device has had any "fixup" workaround running on it, encoded as
-   a boolean. This information is provided to help troubleshooting
-   PHY configurations.
diff --git a/Documentation/ABI/testing/sysfs-class-net-phydev 
b/Documentation/ABI/testing/sysfs-class-net-phydev
index 6ebabfb27912..2a5723343aba 100644
--- a/Documentation/ABI/testing/sysfs-class-net-phydev
+++ b/Documentation/ABI/testing/sysfs-class-net-phydev
@@ -11,24 +11,31 @@ Date:   February 2014
 KernelVersion: 3.15
 Contact:   net...@vger.kernel.org
 Description:
-   Boolean value indicating whether the PHY device has
-   any fixups registered against it (phy_register_fixup)
+   This attribute contains the boolean value whether a given PHY
+   device has had any "fixup" workaround running on it, encoded as
+   a boolean. This information is provided to help troubleshooting
+   PHY configurations.
 
 What:  /sys/class/mdio_bus///phy_id
 Date:  November 2012
 KernelVersion: 3.8
 Contact:   net...@vger.kernel.org
 Description:
-   32-bit hexadecimal value corresponding to the PHY device's OUI,
-   model and revision number.
+   This attribute contains the 32-bit PHY Identifier as reported
+   by the device during bus enumeration, encoded in hexadecimal.
+   This ID is used to match the device with the appropriate
+   driver.
 
 What:  /sys/class/mdio_bus///phy_interface
 Date:  February 2014
 KernelVersion: 3.15
 Contact:   net...@vger.kernel.org
 Description:
-   String value indicating the PHY interface, possible
-   values are:.
+   This attribute contains the PHY interface as configured by the
+   Ethernet driver during bus enumeration, encoded in string.
+   This interface mode is used to configure the Ethernet MAC with 
the
+   appropriate mode for its data lines to the PHY hardware.
+   Possible values are:
 (not available), mii, gmii, sgmii, tbi, rev-mii,
rmii, rgmii, rgmii-id, rgmii-rxid, rgmii-txid, rtbi, smii
xgmii, moca, qsgmii, trgmii, 1000base-x, 2500base-x, rxaui,
-- 
2.17.1

Re: [PATCH net-next v2 1/2] i2c: acpi: export i2c_acpi_find_adapter_by_handle



Wolfram Sang writes:

> On Fri, May 24, 2019 at 05:53:01PM -0700, Ruslan Babayev wrote:
>> This allows drivers to lookup i2c adapters on ACPI based systems similar to
>> of_get_i2c_adapter_by_node() with DT based systems.
>> 
>> Signed-off-by: Ruslan Babayev 
>> Cc: xe-linux-exter...@cisco.com
>
> Please have a look how your patches look in my inbox:
>
> May 05 Ruslan Babayev  ( 129) [PATCH] net: phy: sfp: enable i2c-bus detection 
> on ACPI based systems
> May 05 Ruslan Babayev  (  65) ├─>[PATCH 1/2] i2c: acpi: export 
> i2c_acpi_find_adapter_by_handle
> May 24 Ruslan Babayev  (  65) └─>[PATCH net-next v2 1/2] i2c: acpi: export 
> i2c_acpi_find_adapter_by_handle
> May 05 Ruslan Babayev  (  65) [PATCH net-next 1/2] i2c: acpi: export 
> i2c_acpi_find_adapter_by_handle
> May 06 Ruslan Babayev  (   3) ├─>[PATCH RFC v2 net-next] Enable SFP support 
> on ACPI
> May 06 Ruslan Babayev  (  65) ├─>[PATCH RFC v2 net-next 1/2] i2c: acpi: 
> export i2c_acpi_find_adapter_by_handle
> May 06 Ruslan Babayev  ( 120) └─>[PATCH RFC v2 net-next 2/2] net: phy: sfp: 
> enable i2c-bus detection on ACPI based systems
> May 07 Ruslan Babayev  ( 154)   └─&─>
> May 07 Ruslan Babayev  (  10) └─>
> May 22 Ruslan Babayev  (  29)   └─>
> May 05 Ruslan Babayev  (  93) [PATCH net-next 2/2] net: phy: sfp: enable 
> i2c-bus detection on ACPI based systems
> May 06 Ruslan Babayev  (  25) ├─&─>
> May 06 Ruslan Babayev  (  99) └─&─>
>
> This is highly confusing, and super hard to find out which patches belong
> together. v2 2/2 seems even missing. Please resend this as a new series 
> without
> any in-reply-to, and a fresh cover-letter, so I know which one to apply to my
> tree.
>
> Thanks,
>
>Wolfram

Will do, sorry about that.

Re: [PATCH v1] KVM: x86: PMU Whitelist

2019-05-27 Thread Wei Wang


On 05/23/2019 06:23 AM, Eric Hankland wrote:

- Add a VCPU ioctl that can control which events the guest can monitor.

Signed-off-by: ehankland 
---
Some events can provide a guest with information about other guests or the
host (e.g. L3 cache stats); providing the capability to restrict access
to a "safe" set of events would limit the potential for the PMU to be used
in any side channel attacks. This change introduces a new vcpu ioctl that
sets an event whitelist. If the guest attempts to program a counter for
any unwhitelisted event, the kernel counter won't be created, so any
RDPMC/RDMSR will show 0 instances of that event.


The general idea sounds good to me :)

For the implementation, I would have the following suggestions:

1) Instead of using a whitelist, it would be better to use a blacklist to
forbid the guest from counting any core level information. So by default,
kvm maintains a list of those core level events, which are not supported to
the guest.

The userspace ioctl removes the related events from the blacklist to
make them usable by the guest.

2) Use vm ioctl, instead of vcpu ioctl. The blacklist-ed events can be 
VM wide

(unnecessary to make each CPU to maintain the same copy).
Accordingly, put the pmu event blacklist into kvm->arch.

3) Returning 1 when the guest tries to set the evetlsel msr to count an
event which is on the blacklist.

Best,
Wei

[PATCH v2 3/3] powerpc/pseries: Allow user-specified PCI resource alignment after init

On pseries, custom PCI resource alignment specified with the commandline
argument pci=resource_alignment is disabled due to PCI resources being
managed by the firmware. However, in the case of PCI hotplug the
resources are managed by the kernel, so custom alignments should be
honored in these cases. This is done by only honoring custom
alignments after initial PCI initialization is done, to ensure that
all devices managed by the firmware are excluded.

Without this ability, sub-page BARs sometimes get mapped in between
page boundaries for hotplugged devices and are therefore unusable
with the VFIO framework. This change allows users to request
page alignment for devices they wish to access via VFIO using
the pci=resource_alignment commandline argument.

In the future, this could be extended to provide page-aligned
resources by default for hotplugged devices, similar to what is
done on powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned")

Signed-off-by: Shawn Anastasio 
---
 arch/powerpc/include/asm/machdep.h |  3 +++
 arch/powerpc/kernel/pci-common.c   |  9 +
 arch/powerpc/platforms/pseries/setup.c | 22 ++
 3 files changed, 34 insertions(+)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 2fbfaa9176ed..46eb62c0954e 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -179,6 +179,9 @@ struct machdep_calls {
 
resource_size_t (*pcibios_default_alignment)(void);
 
+   /* Called when determining PCI resource alignment */
+   int (*pcibios_ignore_alignment_request)(void);
+
 #ifdef CONFIG_PCI_IOV
void (*pcibios_fixup_sriov)(struct pci_dev *pdev);
resource_size_t (*pcibios_iov_resource_alignment)(struct pci_dev *, int 
resno);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index ff4b7539cbdf..1a6ded45a701 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -238,6 +238,15 @@ resource_size_t pcibios_default_alignment(void)
return 0;
 }
 
+resource_size_t pcibios_ignore_alignment_request(void)
+{
+   if (ppc_md.pcibios_ignore_alignment_request)
+   return ppc_md.pcibios_ignore_alignment_request();
+
+   /* Fall back to default method of checking PCI_PROBE_ONLY */
+   return pci_has_flag(PCI_PROBE_ONLY);
+}
+
 #ifdef CONFIG_PCI_IOV
 resource_size_t pcibios_iov_resource_alignment(struct pci_dev *pdev, int resno)
 {
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index e4f0dfd4ae33..07f03be02afe 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -82,6 +82,8 @@ EXPORT_SYMBOL(CMO_PageSize);
 
 int fwnmi_active;  /* TRUE if an FWNMI handler is present */
 
+static int initial_pci_init_done; /* TRUE if initial pcibios init has 
completed */
+
 static void pSeries_show_cpuinfo(struct seq_file *m)
 {
struct device_node *root;
@@ -749,6 +751,23 @@ static resource_size_t 
pseries_pci_iov_resource_alignment(struct pci_dev *pdev,
 }
 #endif
 
+static void pseries_after_init(void)
+{
+   initial_pci_init_done = 1;
+}
+
+static int pseries_ignore_alignment_request(void)
+{
+   if (initial_pci_init_done)
+   /*
+* Allow custom alignments after init for things
+* like PCI hotplugging.
+*/
+   return 0;
+
+   return pci_has_flag(PCI_PROBE_ONLY);
+}
+
 static void __init pSeries_setup_arch(void)
 {
set_arch_panic_timeout(10, ARCH_PANIC_TIMEOUT);
@@ -797,6 +816,9 @@ static void __init pSeries_setup_arch(void)
}
 
ppc_md.pcibios_root_bridge_prepare = pseries_root_bridge_prepare;
+   ppc_md.pcibios_after_init = pseries_after_init;
+   ppc_md.pcibios_ignore_alignment_request =
+   pseries_ignore_alignment_request;
 }
 
 static void pseries_panic(char *str)
-- 
2.20.1

[PATCH v2 2/3] powerpc/64: Enable pcibios_after_init hook on ppc64

Enable the pcibios_after_init hook on all powerpc platforms.
This hook is executed at the end of pcibios_init and was previously
only available on CONFIG_PPC32.

Since it is useful and not inherently limited to 32-bit mode,
remove the limitation and allow it on all powerpc platforms.

Signed-off-by: Shawn Anastasio 
---
 arch/powerpc/include/asm/machdep.h | 3 +--
 arch/powerpc/kernel/pci_64.c   | 4 
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 2f0ca6560e47..2fbfaa9176ed 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -150,6 +150,7 @@ struct machdep_calls {
void(*init)(void);
 
void(*kgdb_map_scc)(void);
+#endif /* CONFIG_PPC32 */
 
/*
 * optional PCI "hooks"
@@ -157,8 +158,6 @@ struct machdep_calls {
/* Called at then very end of pcibios_init() */
void (*pcibios_after_init)(void);
 
-#endif /* CONFIG_PPC32 */
-
/* Called in indirect_* to avoid touching devices */
int (*pci_exclude_device)(struct pci_controller *, unsigned char, 
unsigned char);
 
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 9d8c10d55407..fba7fe6e4a50 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -68,6 +68,10 @@ static int __init pcibios_init(void)
 
printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
 
+   /* Call machine dependent post-init code */
+   if (ppc_md.pcibios_after_init)
+   ppc_md.pcibios_after_init();
+
return 0;
 }
 
-- 
2.20.1

[PATCH v2 1/3] PCI: Introduce pcibios_ignore_alignment_request

Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine whether or not to ignore alignment requests for PCI resources.

The existing behavior is to simply ignore alignment requests when
PCI_PROBE_ONLY is set. This is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.

Signed-off-by: Shawn Anastasio 
---
 drivers/pci/pci.c   | 9 +++--
 include/linux/pci.h | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8abc843b1615..8207a09085d1 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5882,6 +5882,11 @@ resource_size_t __weak pcibios_default_alignment(void)
return 0;
 }
 
+int __weak pcibios_ignore_alignment_request(void)
+{
+   return pci_has_flag(PCI_PROBE_ONLY);
+}
+
 #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
 static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
 static DEFINE_SPINLOCK(resource_alignment_lock);
@@ -5906,9 +5911,9 @@ static resource_size_t 
pci_specified_resource_alignment(struct pci_dev *dev,
p = resource_alignment_param;
if (!*p && !align)
goto out;
-   if (pci_has_flag(PCI_PROBE_ONLY)) {
+   if (pcibios_ignore_alignment_request()) {
align = 0;
-   pr_info_once("PCI: Ignoring requested alignments 
(PCI_PROBE_ONLY)\n");
+   pr_info_once("PCI: Ignoring requested alignments\n");
goto out;
}
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4a5a84d7bdd4..47471dcdbaf9 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1990,6 +1990,7 @@ static inline void pcibios_penalize_isa_irq(int irq, int 
active) {}
 int pcibios_alloc_irq(struct pci_dev *dev);
 void pcibios_free_irq(struct pci_dev *dev);
 resource_size_t pcibios_default_alignment(void);
+int pcibios_ignore_alignment_request(void);
 
 #ifdef CONFIG_HIBERNATE_CALLBACKS
 extern struct dev_pm_ops pcibios_pm_ops;
-- 
2.20.1

[PATCH v2 0/3] Allow custom PCI resource alignment on pseries

Changes from v1 to v2:
  - Fix function declaration warnings caught by sparse

Hello all,

This patch set implements support for user-specified PCI resource
alignment on the pseries platform for hotplugged PCI devices.
Currently on pseries, PCI resource alignments specified with the
pci=resource_alignment commandline argument are ignored, since
the firmware is in charge of managing the PCI resources. In the
case of hotplugged devices, though, the kernel is in charge of 
configuring the resources and should obey alignment requirements.

The current behavior of ignoring the alignment for hotplugged devices
results in sub-page BARs landing between page boundaries and
becoming un-mappable from userspace via the VFIO framework.
This issue was observed on a pseries KVM guest with hotplugged
ivshmem devices.
 
With these changes, users can specify an appropriate
pci=resource_alignment argument on boot for devices they wish to use 
with VFIO.

In the future, this could be extended to provide page-aligned
resources by default for hotplugged devices, similar to what is done
on powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned").

Feedback is appreciated.

Thanks,
Shawn

Shawn Anastasio (3):
  PCI: Introduce pcibios_ignore_alignment_request
  powerpc/64: Enable pcibios_after_init hook on ppc64
  powerpc/pseries: Allow user-specified PCI resource alignment after
init

 arch/powerpc/include/asm/machdep.h |  6 --
 arch/powerpc/kernel/pci-common.c   |  9 +
 arch/powerpc/kernel/pci_64.c   |  4 
 arch/powerpc/platforms/pseries/setup.c | 22 ++
 drivers/pci/pci.c  |  9 +++--
 include/linux/pci.h|  1 +
 6 files changed, 47 insertions(+), 4 deletions(-)

-- 
2.20.1

Re: [v3, PATCH] net: stmmac: add support for hash table size 128/256 in dwmac4

2019-05-27 Thread biao huang

Dear David,

On Mon, 2019-05-27 at 10:08 -0700, David Miller wrote:
> From: Biao Huang 
> Date: Mon, 27 May 2019 11:14:27 +0800
> 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
> > b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> > index 5e98da4..029a3db 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> > @@ -403,41 +403,50 @@ static void dwmac4_set_filter(struct mac_device_info 
> > *hw,
> >   struct net_device *dev)
> >  {
> > void __iomem *ioaddr = (void __iomem *)dev->base_addr;
> > -   unsigned int value = 0;
> > +   unsigned int value;
> > +   int numhashregs = (hw->multicast_filter_bins >> 5);
> > +   int mcbitslog2 = hw->mcast_bits_log2;
> > +   int i;
> 
> Please retain the reverse christmas tree ordering here.
I'm a little confused about the reverse xmas tree ordering.

should I reorder them only according to the total length like this:

void __iomem *ioaddr = (void __iomem *)dev->base_addr;
int numhashregs = (hw->multicast_filter_bins >> 5);
int mcbitslog2 = hw->mcast_bits_log2;
unsigned int value;
int i;

or should I gather the same type together, and order types as reverse
xmas tree, then order the same type definitions as reverse xmas tree,
like this:

void __iomem *ioaddr = (void __iomem *)dev->base_addr;
unsigned int value;
int numhashregs = (hw->multicast_filter_bins >> 5);
int mcbitslog2 = hw->mcast_bits_log2;
int i;

Thank you.
> 
> Thank you.

Re: [PATCH net-next] net: link_watch: prevent starvation when processing linkwatch wq

2019-05-27 Thread Yunsheng Lin

On 2019/5/28 9:17, Stephen Hemminger wrote:
> On Tue, 28 May 2019 09:04:18 +0800
> Yunsheng Lin  wrote:
> 
>> On 2019/5/27 22:58, Stephen Hemminger wrote:
>>> On Mon, 27 May 2019 09:47:54 +0800
>>> Yunsheng Lin  wrote:
>>>   
 When user has configured a large number of virtual netdev, such
 as 4K vlans, the carrier on/off operation of the real netdev
 will also cause it's virtual netdev's link state to be processed
 in linkwatch. Currently, the processing is done in a work queue,
 which may cause worker starvation problem for other work queue.

 This patch releases the cpu when link watch worker has processed
 a fixed number of netdev' link watch event, and schedule the
 work queue again when there is still link watch event remaining.

 Signed-off-by: Yunsheng Lin   
>>>
>>> Why not put link watch in its own workqueue so it is scheduled
>>> separately from the system workqueue?  
>>
>> From testing and debuging, the workqueue runs on the cpu where the
>> workqueue is schedule when using normal workqueue, even using its
>> own workqueue instead of system workqueue. So if the cpu is busy
>> processing the linkwatch event, it is not able to process other
>> workqueue' work when the workqueue is scheduled on the same cpu.
>>
>> Using unbound workqueue may solve the cpu starvation problem.
>> But the __linkwatch_run_queue is called with rtnl_lock, so if it
>> takes a lot time to process, other need to take the rtnl_lock may
>> not be able to move forward.
> 
> Agree with the starvation issue. My cocern is that large number of
> events that end up being delayed would impact things that are actually
> watching for link events (like routing daemons).

Agreed. I am not familiar with above use cases, it would be very helpful
if someone can help testing the impact of above use case.

> 
> It probably would be not accepted to do rtnl_unlock/sched_yield/rtnl_lock
> in the loop, but that is another alternative.

Yes. But seems not very efficient to do rtnl_unlock/sched_yield/rtnl_lock
for very linkwatch_do_dev.

> 
> 
> 
> .
>

Re: [PATCH v3 0/8] Fix Elan I2C touchpads in latest generation from Lenovo

2019-05-27 Thread Dmitry Torokhov

On Fri, May 24, 2019 at 03:50:38PM +0200, Benjamin Tissoires wrote:
> Here comes the v3.
> 
> Very few changes from v2:
> - dropped the last 2 patches where I tried to be smart, and it turns out
>   that it was not very a good idea
> - also removed the only other blacklisted model, as it has been tested with
>   the v2 and it is also now working properly

Applied the lot, thank you.

> 
> Cheers,
> Benjamin
> 
> Benjamin Tissoires (8):
>   Input: elantech - query the min/max information beforehand too
>   Input: elantech - add helper function elantech_is_buttonpad()
>   Input: elantech - detect middle button based on firmware version
>   dt-bindings: add more optional properties for elan_i2c touchpads
>   Input: elan_i2c - do not query the info if they are provided
>   Input: elantech/SMBus - export all capabilities from the PS/2 node
>   Input: elan_i2c - handle physical middle button
>   Input: elantech: remove P52 and P72 from SMBus blacklist
> 
>  .../devicetree/bindings/input/elan_i2c.txt|  11 +
>  drivers/input/mouse/elan_i2c_core.c   |  72 +++-
>  drivers/input/mouse/elantech.c| 320 ++
>  drivers/input/mouse/elantech.h|   8 +
>  4 files changed, 246 insertions(+), 165 deletions(-)
> 
> -- 
> 2.21.0
> 

-- 
Dmitry

Re: linux-next: manual merge of the scsi tree with Linus' tree

2019-05-27 Thread Stephen Rothwell

Hi all,

On Wed, 22 May 2019 10:08:34 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the scsi tree got conflicts in:
> 
>   drivers/scsi/hosts.c
>   drivers/scsi/libsas/sas_task.c
>   drivers/scsi/scsi.c
>   drivers/scsi/scsi_error.c
>   drivers/scsi/scsi_ioctl.c
>   drivers/scsi/scsi_lib.c
>   drivers/scsi/scsi_pm.c
>   drivers/scsi/scsi_sysfs.c
>   drivers/scsi/sd.c
>   drivers/scsi/sr.c
>   drivers/scsi/st.c
> 
> between commits:
> 
>   457c89965399 ("treewide: Add SPDX license identifier for missed files")
>   09c434b8a004 ("treewide: Add SPDX license identifier for more missed files")
> 
> from Linus' tree and commits:
> 
>   026104bfa591 ("scsi: core: add SPDX tags to scsi midlayer files missing 
> licensing information")
>   5502239e73e6 ("scsi: libsas: add a SPDX tag to sas_task.c")
>   5897b844b7f9 ("scsi: sd: add a SPDX tag to sd.c")
>   95b04a2ff9c7 ("scsi: sr: add a SPDX tag to sr.c")
>   50a1ea5bebbc ("scsi: st: add a SPDX tag to st.c")

I have now got more of these conflicts in

drivers/scsi/libsas/sas_init.c
drivers/scsi/libsas/sas_internal.h
drivers/scsi/libsas/sas_scsi_host.c
drivers/scsi/sg.c
include/scsi/libsas.h
include/scsi/sas.h

-- 
Cheers,
Stephen Rothwell


pgpQb44fFRyOL.pgp
Description: OpenPGP digital signature

RE: [PATCH 1/2] vfio: ABI for setting mdev display flip eventfd

2019-05-27 Thread Zhang, Tina



> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Alex Williamson
> Sent: Monday, May 27, 2019 10:05 PM
> To: Zhang, Tina 
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org;
> zhen...@linux.intel.com; Yuan, Hang ;
> kra...@redhat.com; intel-gvt-...@lists.freedesktop.org; Lv, Zhiyuan
> 
> Subject: Re: [PATCH 1/2] vfio: ABI for setting mdev display flip eventfd
> 
> On Mon, 27 May 2019 16:43:11 +0800
> Tina Zhang  wrote:
> 
> > Add VFIO_DEVICE_SET_GFX_FLIP_EVENTFD ioctl command to set eventfd
> > based signaling mechanism to deliver vGPU framebuffer page flip event
> > to userspace.
> >
> > Signed-off-by: Tina Zhang 
> > ---
> >  include/uapi/linux/vfio.h | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 02bb7ad6e986..27300597717f 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -696,6 +696,18 @@ struct vfio_device_ioeventfd {
> >
> >  #define VFIO_DEVICE_IOEVENTFD  _IO(VFIO_TYPE, VFIO_BASE +
> 16)
> >
> > +/**
> > + * VFIO_DEVICE_SET_GFX_FLIP_EVENTFD - _IOW(VFIO_TYPE, VFIO_BASE
> + 17,
> > +__s32)
> > + *
> > + * Set eventfd based signaling mechanism to deliver vGPU framebuffer
> > +page
> > + * flip event to userspace. A value of -1 is used to stop the page
> > +flip
> > + * delivering.
> > + *
> > + * Return: 0 on success, -errno on failure.
> > + */
> > +
> > +#define VFIO_DEVICE_SET_GFX_FLIP_EVENTFD _IO(VFIO_TYPE,
> VFIO_BASE +
> > +17)
> > +
> >  /*  API for Type1 VFIO IOMMU  */
> >
> >  /**
> 
> Why can't we use VFIO_DEVICE_SET_IRQS for this?  We can add a capability
> to vfio_irq_info in the same way that we did for regions to describe device
> specific IRQ support.  Thanks,
Add a new kind of index, like this?
enum {
VFIO_PCI_INTX_IRQ_INDEX,
VFIO_PCI_MSI_IRQ_INDEX,
VFIO_PCI_MSIX_IRQ_INDEX,
VFIO_PCI_ERR_IRQ_INDEX,
VFIO_PCI_REQ_IRQ_INDEX,
+  VFIO_PCI_GFX_FLIP_EVENT_INDEX,
VFIO_PCI_NUM_IRQS
};
Perhaps this is what we don't want. This VFIO_PCI_GFX_FLIP_EVENT_INDEX is 
specific to graphics card and it's actually an event which is reported by 
INTX/MSI/ MSIX IRQ.
Thanks.

BR,
Tina
> 
> Alex
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

答复: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.

2019-05-27 Thread Xiaoxiao Liu

Add Saito-san.

Hi Hui,
Does it mean that your device (reported to kernel) sends only trackstick 
packets and not touchpad?
-> Yes.
I guess that you want parenthesis around (param[1] & 0x20). And also describe 
what that 0x20 constant means.
It is not a warning.
-> Yes, it should be (param[1] & 0x20). 
-> 0x20 is used for detect which type device is. I will correct it.

Hm... why your device does not match these constants?
->I am not clear what the alps_command_mode_read_reg(psmouse, 0xD7) 
used for.
  -> But I know our device did not meet the condition if (reg_val 
== 0x0C || reg_val == 0x1D) from therunning result.

Xiaoxiao Liu
xiaoxiao.li...@cn.alps.com
sliuuxiaonx...@gmail.com
-邮件原件-
发件人: Pali Rohár  
发送时间: Monday, May 27, 2019 6:09 PM
收件人: XiaoXiao Liu 
抄送: dmitry.torok...@gmail.com; peter.hutte...@who-t.net; 
hui.w...@canonical.com; linux-in...@vger.kernel.org; 
linux-kernel@vger.kernel.org; 曹 曉建 Xiaojian Cao ; 
zhang...@lenovo.com; 劉 曉曉 Xiaoxiao Liu 
主题: Re: [PATCH] input: alps-fix the issue alps cs19 trackstick do not work.

Hi!

On Monday 27 May 2019 05:44:22 XiaoXiao Liu wrote:
> The alps devices which detected to use the ALPS_PROTO_V8 procotol 
> contains ALPS touchpad and ALPS trackstick.The ALPS_PROTO_V8 procotol 
> do not support the trackstick device process by default.

Normally PS/2 device handled by alps.c is touchpad and in some cases touchpad 
sends also trackstick data in that one PS/2 channel.

Does it mean that your device (reported to kernel) sends only trackstick 
packets and not touchpad?

> When the trackstick was detected to use ALPS_PROTO_V8 procotol, the v8 
> process_packet method alps_process_packet_ss4_v2 will reject to report 
> the data when the device using ALPS_PROTO_V8 procotol is not set the 
> ALPS_DUALPOINT flag.
> 
> The alps cs19 trackstick is detected to use the ALPS_PROTO_V8 procotol 
> but without ALPS_DUALPOINT flag, the alps driver will not report the 
> input data. so the trackstick will not work.
> 
> solution: when the alps cs19 device detected, set the device 
> ALPS_DUALPOINT flag,then the input data will be processed.
> 
> Signed-off-by: XiaoXiao Liu 
> ---
>  drivers/input/mouse/alps.c | 25 +++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c 
> index 0a6f7ca883e7..a54677cf7474 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -24,7 +24,7 @@
>  
>  #include "psmouse.h"
>  #include "alps.h"
> -
> +#include "trackpoint.h"
>  /*
>   * Definitions for ALPS version 3 and 4 command mode protocol
>   */
> @@ -220,6 +220,23 @@ static bool alps_is_valid_first_byte(struct alps_data 
> *priv,
>   return (data & priv->mask0) == priv->byte0;  }
>  
> +static int alps_check_cs19_trackstick(struct psmouse *psmouse) {
> + u8 param[2] = { 0 };
> + int error;
> +
> + error = ps2_command(>ps2dev,
> + param, MAKE_PS2_CMD(0, 2, TP_READ_ID));
> + if (error)
> + return error;
> +
> + if (param[0] == TP_VARIANT_ALPS && param[1] & 0x20) {

I guess that you want parenthesis around (param[1] & 0x20). And also describe 
what that 0x20 constant means.

> + psmouse_warn(psmouse, "It is alps cs19 trackstick");

It is not a warning.

> + return 0;
> + }
> + return -1;
> +}
> +
>  static void alps_report_buttons(struct input_dev *dev1, struct input_dev 
> *dev2,
>   int left, int right, int middle)
>  {
> @@ -2568,8 +2585,12 @@ static int alps_update_dual_info_ss4_v2(unsigned char 
> otp[][4],
>   alps_exit_command_mode(psmouse);
>   ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
>  
> - if (reg_val == 0x0C || reg_val == 0x1D)
> + if (reg_val == 0x0C || reg_val == 0x1D) {

Hm... why your device does not match these constants?

> + is_dual = true;
> + } else if (alps_check_cs19_trackstick(psmouse) == 0) {
> + //For support Thinkpad CS19 TrackStick
>   is_dual = true;
> + }
>   }
>   }
>  

--
Pali Rohár
pali.ro...@gmail.com

Re: memory leak in sctp_process_init

2019-05-27 Thread Marcelo Ricardo Leitner

On Mon, May 27, 2019 at 05:48:06PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:9c7db500 Merge tag 'selinux-pr-20190521' of git://git.kern..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10388530a0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=61dd9e15a761691d
> dashboard link: https://syzkaller.appspot.com/bug?extid=f7e9153b037eac9b1df8
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10e32f8ca0
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=177fa530a0
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+f7e9153b037eac9b1...@syzkaller.appspotmail.com
> 
>  0 to HW filter on device batadv0
> executing program
> executing program
> executing program
> BUG: memory leak
> unreferenced object 0x88810ef68400 (size 1024):
>   comm "syz-executor273", pid 7046, jiffies 4294945598 (age 28.770s)
>   hex dump (first 32 bytes):
> 1d de 28 8d de 0b 1b e3 b5 c2 f9 68 fd 1a 97 25  ..(h...%
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
> [] kmemleak_alloc_recursive
> include/linux/kmemleak.h:55 [inline]
> [] slab_post_alloc_hook mm/slab.h:439 [inline]
> [] slab_alloc mm/slab.c:3326 [inline]
> [] __do_kmalloc mm/slab.c:3658 [inline]
> [] __kmalloc_track_caller+0x15d/0x2c0 mm/slab.c:3675
> [<9e6245e6>] kmemdup+0x27/0x60 mm/util.c:119
> [] kmemdup include/linux/string.h:432 [inline]
> [] sctp_process_init+0xa7e/0xc20
> net/sctp/sm_make_chunk.c:2437
> [] sctp_cmd_process_init net/sctp/sm_sideeffect.c:682
> [inline]
> [] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1384
> [inline]
> [] sctp_side_effects net/sctp/sm_sideeffect.c:1194
> [inline]
> [] sctp_do_sm+0xbdc/0x1d60
> net/sctp/sm_sideeffect.c:1165

Note that this is on the client side. It was handling the INIT_ACK
chunk, from sctp_sf_do_5_1C_ack().

I'm not seeing anything else other than sctp_association_free()
releasing this memory. This means 2 things:
- Every time the cookie is retransmitted, it leaks. As shown by the
  repetitive leaks here.
- The cookie remains allocated throughout the association, which is
  also not good as that's a 1k that we could have released back to the
  system right after the handshake.

  Marcelo

Re: [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor

2019-05-27 Thread Chanwoo Choi

Hi Sibi,

On 19. 5. 27. 오후 5:23, Sibi Sankar wrote:
> Hey Chanwoo,
> 
> Thanks a lot for reviewing the patch. Like I
> had indicated earlier we decided to go with
> a simpler approach instead on qualcomm SoCs.
> I am happy to re-spin this patch with your
> comments addressed if we do find other users
> for this feature.

Actually, I think that this approach is necessary.
On many real released product like smartphone
have the dependency between cpufreq and devfreq
for memory bus bandwidth. For example, when playing
the video or get the 60fps without loss.

If possible, this patch should be ongoing on either
now or future. Thanks.

> 
> On 2019-04-12 13:09, Chanwoo Choi wrote:
>> Hi,
>>
>> I agree this approach absolutely.
>> Just I add some comments. Please check it.
>>
>> On 19. 3. 29. 오전 12:28, Sibi Sankar wrote:
>>> From: Saravana Kannan 
>>>
>>> Many CPU architectures have caches that can scale independent of the
>>> CPUs. Frequency scaling of the caches is necessary to make sure the cache
>>> is not a performance bottleneck that leads to poor performance and
>>> power. The same idea applies for RAM/DDR.
>>>
>>> To achieve this, this patch add support for cpu based scaling to the
>>> passive governor. This is accomplished by taking the current frequency
>>> of each CPU frequency domain and then adjusts the frequency of the cache
>>> (or any devfreq device) based on the frequency of the CPUs. It listens
>>> to CPU frequency transition notifiers to keep itself up to date on the
>>> current CPU frequency.
>>>
>>> To decide the frequency of the device, the governor does one of the
>>> following:
>>> * Constructs a CPU frequency to device frequency mapping table from
>>>   required-opps property of the devfreq device's opp_table
>>>
>>> * Scales the device frequency in proportion to the CPU frequency. So, if
>>>   the CPUs are running at their max frequency, the device runs at its
>>>   max frequency. If the CPUs are running at their min frequency, the
>>>   device runs at its min frequency. It is interpolated for frequencies
>>>   in between.
>>>
>>> Signed-off-by: Saravana Kannan 
>>> [Sibi: Integrated cpu-freqmap governor into passive_governor]
>>> Signed-off-by: Sibi Sankar 
>>> ---
>>>  drivers/devfreq/Kconfig    |   4 +
>>>  drivers/devfreq/governor_passive.c | 276 -
>>>  include/linux/devfreq.h    |  43 -
>>>  3 files changed, 315 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>>> index 6a172d338f6d..9a45f464a56b 100644
>>> --- a/drivers/devfreq/Kconfig
>>> +++ b/drivers/devfreq/Kconfig
>>> @@ -72,6 +72,10 @@ config DEVFREQ_GOV_PASSIVE
>>>    device. This governor does not change the frequency by itself
>>>    through sysfs entries. The passive governor recommends that
>>>    devfreq device uses the OPP table to get the frequency/voltage.
>>> +  Alternatively the governor can also be chosen to scale based on
>>> +  the online CPUs current frequency. A CPU frequency to device
>>> +  frequency mapping table(s) is auto-populated by the governor
>>> +  for this purpose.
>>>
>>>  comment "DEVFREQ Drivers"
>>>
>>> diff --git a/drivers/devfreq/governor_passive.c 
>>> b/drivers/devfreq/governor_passive.c
>>> index 3bc29acbd54e..2506682b233b 100644
>>> --- a/drivers/devfreq/governor_passive.c
>>> +++ b/drivers/devfreq/governor_passive.c
>>> @@ -11,10 +11,63 @@
>>>   */
>>>
>>>  #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>  #include "governor.h"
>>>
>>> +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data 
>>> *data,
>>> + unsigned int cpu)
>>> +{
>>> +    unsigned int cpu_min, cpu_max;
>>> +    struct devfreq *devfreq = (struct devfreq *)data->this;
>>> +    unsigned int dev_min, dev_max, cpu_percent, cpu_freq = 0, freq = 0;
>>> +    unsigned long *freq_table = devfreq->profile->freq_table;
>>> +    struct device *dev = devfreq->dev.parent;
>>> +    struct devfreq_map *map;
>>> +    int opp_cnt, i;
>>> +
>>> +    if (!data->state[cpu] || data->state[cpu]->first_cpu != cpu) {
>>> +    freq = 0;
>>> +    goto out;
>>
>> goto out -> return 0;
>>
>>> +    }
>>> +
>>> +    /* Use Interpolation if map is not available */
>>> +    cpu_freq = data->state[cpu]->freq;
>>> +    if (!data->map) {
>>> +    cpu_min = data->state[cpu]->min_freq;
>>> +    cpu_max = data->state[cpu]->max_freq;
>>> +    if (freq_table) {
>>> +    dev_min = freq_table[0];
>>> +    dev_max = freq_table[devfreq->profile->max_state - 1];
>>
>> Actually, it is not always true. The devfreq recommend the ascending order 
>> for
>> 'freq_table'. But, it is not mandatory. Also, some devfreq device uses the
>> decending order for 'freq_table'. So, a patch[1] was considering the order
>> when getting the minimum/maximum frequency from freq_table.
>>
>> If you want to get the

[Patch v2] target/iscsi: fix possible condition with no effect (if == else)

2019-05-27 Thread Hariprasad Kelam

fix below warning reported by coccicheck

drivers/target/iscsi/iscsi_target_nego.c:175:6-8: WARNING: possible
condition with no effect (if == else)

Signed-off-by: Hariprasad Kelam 
---
Changes in v2: treat SRP as unsupported authtype.
   Remove unnecessary else
   return 2 in all unsupported cases

---
---
 drivers/target/iscsi/iscsi_target_nego.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target_nego.c 
b/drivers/target/iscsi/iscsi_target_nego.c
index 8a5e8d1..92ce2fd 100644
--- a/drivers/target/iscsi/iscsi_target_nego.c
+++ b/drivers/target/iscsi/iscsi_target_nego.c
@@ -160,22 +160,11 @@ static u32 iscsi_handle_authentication(
 
if (strstr("None", authtype))
return 1;
-#ifdef CANSRP
-   else if (strstr("SRP", authtype))
-   return srp_main_loop(conn, auth, in_buf, out_buf,
-   _length, out_length);
-#endif
else if (strstr("CHAP", authtype))
return chap_main_loop(conn, auth, in_buf, out_buf,
_length, out_length);
-   else if (strstr("SPKM1", authtype))
-   return 2;
-   else if (strstr("SPKM2", authtype))
-   return 2;
-   else if (strstr("KRB5", authtype))
-   return 2;
-   else
-   return 2;
+   /* SRP, SPKM1, SPKM2 and KRB5 are unsupported */
+   return 2;
 }
 
 static void iscsi_remove_failed_auth_entry(struct iscsi_conn *conn)
-- 
2.7.4

Re: [PATCH v2 08/10] Input: elan_i2c - export true width/height

2019-05-27 Thread 'Dmitry Torokhov'

Hi Benjamin, KT,

On Mon, May 27, 2019 at 11:55:01AM +0800, 廖崇榮 wrote:
> Hi
> 
> -Original Message-
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] 
> Sent: Friday, May 24, 2019 5:37 PM
> To: Dmitry Torokhov; KT Liao; Rob Herring; Aaron Ma; Hans de Goede
> Cc: open list:HID CORE LAYER; lkml; devicet...@vger.kernel.org
> Subject: Re: [PATCH v2 08/10] Input: elan_i2c - export true width/height
> 
> On Tue, May 21, 2019 at 3:28 PM Benjamin Tissoires 
>  wrote:
> >
> > The width/height is actually in the same unit than X and Y. So we 
> > should not tamper the data, but just set the proper resolution, so 
> > that userspace can correctly detect which touch is a palm or a finger.
> >
> > Signed-off-by: Benjamin Tissoires 
> >
> > --
> >
> > new in v2
> > ---
> >  drivers/input/mouse/elan_i2c_core.c | 11 ---
> >  1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/input/mouse/elan_i2c_core.c 
> > b/drivers/input/mouse/elan_i2c_core.c
> > index 7ff044c6cd11..6f4feedb7765 100644
> > --- a/drivers/input/mouse/elan_i2c_core.c
> > +++ b/drivers/input/mouse/elan_i2c_core.c
> > @@ -45,7 +45,6 @@
> >  #define DRIVER_NAME"elan_i2c"
> >  #define ELAN_VENDOR_ID 0x04f3
> >  #define ETP_MAX_PRESSURE   255
> > -#define ETP_FWIDTH_REDUCE  90
> >  #define ETP_FINGER_WIDTH   15
> >  #define ETP_RETRY_COUNT3
> >
> > @@ -915,12 +914,8 @@ static void elan_report_contact(struct elan_tp_data 
> > *data,
> > return;
> > }
> >
> > -   /*
> > -* To avoid treating large finger as palm, let's reduce the
> > -* width x and y per trace.
> > -*/
> > -   area_x = mk_x * (data->width_x - ETP_FWIDTH_REDUCE);
> > -   area_y = mk_y * (data->width_y - ETP_FWIDTH_REDUCE);
> > +   area_x = mk_x * data->width_x;
> > +   area_y = mk_y * data->width_y;
> >
> > major = max(area_x, area_y);
> > minor = min(area_x, area_y); @@ -1123,8 +1118,10 @@ 
> > static int elan_setup_input_device(struct elan_tp_data *data)
> >  ETP_MAX_PRESSURE, 0, 0);
> > input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0,
> >  ETP_FINGER_WIDTH * max_width, 0, 0);
> > +   input_abs_set_res(input, ABS_MT_TOUCH_MAJOR, data->x_res);
> > input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0,
> >  ETP_FINGER_WIDTH * min_width, 0, 0);
> > +   input_abs_set_res(input, ABS_MT_TOUCH_MINOR, data->y_res);
> 
> I had a chat with Peter on Wednesday, and he mentioned that this is dangerous 
> as Major/Minor are max/min of the width and height. And given that we might 
> have 2 different resolutions, we would need to do some computation in the 
> kernel to ensure the data is correct with respect to the resolution.
> 
> TL;DR: I don't think we should export the resolution there :(
> 
> KT, should I drop the patch entirely, or is there a strong argument for 
> keeping the ETP_FWIDTH_REDUCE around?
> I suggest you apply the patch, I have no idea why ETP_FWIDTH_REDUCE existed. 
> Our FW team know nothing about ETP_FWIDTH_REDUCE ether.
> 
> The only side effect will happen on Chromebook because such computation have 
> stayed in ChromeOS' kernel for four years.
> Chrome's finger/palm threshold may be different from other Linux distribution.
> We will discuss it with Google once the patch picked by chrome and cause 
> something wrong.

Chrome has logic that contact with maximum major/minor is treated as a
palm, so here the driver (which originally came from Chrome OS)
artificially reduces the contact size to ensure that palm rejection
logic does not trigger.

I'm adding Harry to confirm whether we are still using this logic and to
see if we can adjust it to be something else.

Thanks.

-- 
Dmitry

Re: memory leak in hsr_create_self_node

2019-05-27 Thread syzbot


syzbot has found a reproducer for the following crash on:

HEAD commit:cd6c84d8 Linux 5.2-rc2
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10aa46c4a0
kernel config:  https://syzkaller.appspot.com/x/.config?x=64479170dcaf0e11
dashboard link: https://syzkaller.appspot.com/bug?extid=c6167ec3de7def23d1e8
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=13787616a0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17a5119aa0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c6167ec3de7def23d...@syzkaller.appspotmail.com

   68.477885][T7] team0 (unregistering): Port device team_slave_0  
removed

BUG: memory leak
unreferenced object 0x8881143dfb00 (size 128):
  comm "syz-executor744", pid 6995, jiffies 4294943713 (age 30.830s)
  hex dump (first 32 bytes):
f0 68 38 15 81 88 ff ff f0 68 38 15 81 88 ff ff  .h8..h8.
ea ff ec 35 72 e3 56 fe 48 40 f2 12 8a 83 76 ee  ...5r.V.H@v.
  backtrace:
[<9a4e4995>] kmemleak_alloc_recursive  
include/linux/kmemleak.h:55 [inline]

[<9a4e4995>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<9a4e4995>] slab_alloc mm/slab.c:3326 [inline]
[<9a4e4995>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<2bcc4522>] kmalloc include/linux/slab.h:547 [inline]
[<2bcc4522>] hsr_create_self_node+0x42/0x150  
net/hsr/hsr_framereg.c:84
[] hsr_dev_finalize+0xa4/0x233  
net/hsr/hsr_device.c:441

[<422bac9b>] hsr_newlink+0xf3/0x140 net/hsr/hsr_netlink.c:69
[<0023c97f>] __rtnl_newlink+0x892/0xb30  
net/core/rtnetlink.c:3191

[<6b30cccb>] rtnl_newlink+0x4e/0x80 net/core/rtnetlink.c:3249
[] rtnetlink_rcv_msg+0x178/0x4b0  
net/core/rtnetlink.c:5218
[] netlink_rcv_skb+0x61/0x170  
net/netlink/af_netlink.c:2486

[<2235e2b8>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5236
[] netlink_unicast_kernel  
net/netlink/af_netlink.c:1311 [inline]
[] netlink_unicast+0x1ec/0x2d0  
net/netlink/af_netlink.c:1337
[] netlink_sendmsg+0x26a/0x480  
net/netlink/af_netlink.c:1926

[<50d30521>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<50d30521>] sock_sendmsg+0x54/0x70 net/socket.c:671
[<52aab806>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
[<7c8496b5>] __do_sys_sendto net/socket.c:1976 [inline]
[<7c8496b5>] __se_sys_sendto net/socket.c:1972 [inline]
[<7c8496b5>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
[<779aa30b>] do_syscall_64+0x76/0x1a0  
arch/x86/entry/common.c:301

[] entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: memory leak
unreferenced object 0x88811406fa40 (size 64):
  comm "syz-executor744", pid 6995, jiffies 4294943713 (age 30.830s)
  hex dump (first 32 bytes):
00 2a b5 14 81 88 ff ff 00 02 00 00 00 00 ad de  .*..
00 60 38 15 81 88 ff ff c0 68 38 15 81 88 ff ff  .`8..h8.
  backtrace:
[<9a4e4995>] kmemleak_alloc_recursive  
include/linux/kmemleak.h:55 [inline]

[<9a4e4995>] slab_post_alloc_hook mm/slab.h:439 [inline]
[<9a4e4995>] slab_alloc mm/slab.c:3326 [inline]
[<9a4e4995>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[<5da31874>] kmalloc include/linux/slab.h:547 [inline]
[<5da31874>] kzalloc include/linux/slab.h:742 [inline]
[<5da31874>] hsr_add_port+0xe7/0x220 net/hsr/hsr_slave.c:142
[] hsr_dev_finalize+0x14f/0x233  
net/hsr/hsr_device.c:472

[<422bac9b>] hsr_newlink+0xf3/0x140 net/hsr/hsr_netlink.c:69
[<0023c97f>] __rtnl_newlink+0x892/0xb30  
net/core/rtnetlink.c:3191

[<6b30cccb>] rtnl_newlink+0x4e/0x80 net/core/rtnetlink.c:3249
[] rtnetlink_rcv_msg+0x178/0x4b0  
net/core/rtnetlink.c:5218
[] netlink_rcv_skb+0x61/0x170  
net/netlink/af_netlink.c:2486

[<2235e2b8>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5236
[] netlink_unicast_kernel  
net/netlink/af_netlink.c:1311 [inline]
[] netlink_unicast+0x1ec/0x2d0  
net/netlink/af_netlink.c:1337
[] netlink_sendmsg+0x26a/0x480  
net/netlink/af_netlink.c:1926

[<50d30521>] sock_sendmsg_nosec net/socket.c:652 [inline]
[<50d30521>] sock_sendmsg+0x54/0x70 net/socket.c:671
[<52aab806>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
[<7c8496b5>] __do_sys_sendto net/socket.c:1976 [inline]
[<7c8496b5>] __se_sys_sendto net/socket.c:1972 [inline]
[<7c8496b5>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
[<779aa30b>]

Re: [PATCH net-next] net: link_watch: prevent starvation when processing linkwatch wq

2019-05-27 Thread Stephen Hemminger

On Tue, 28 May 2019 09:04:18 +0800
Yunsheng Lin  wrote:

> On 2019/5/27 22:58, Stephen Hemminger wrote:
> > On Mon, 27 May 2019 09:47:54 +0800
> > Yunsheng Lin  wrote:
> >   
> >> When user has configured a large number of virtual netdev, such
> >> as 4K vlans, the carrier on/off operation of the real netdev
> >> will also cause it's virtual netdev's link state to be processed
> >> in linkwatch. Currently, the processing is done in a work queue,
> >> which may cause worker starvation problem for other work queue.
> >>
> >> This patch releases the cpu when link watch worker has processed
> >> a fixed number of netdev' link watch event, and schedule the
> >> work queue again when there is still link watch event remaining.
> >>
> >> Signed-off-by: Yunsheng Lin   
> > 
> > Why not put link watch in its own workqueue so it is scheduled
> > separately from the system workqueue?  
> 
> From testing and debuging, the workqueue runs on the cpu where the
> workqueue is schedule when using normal workqueue, even using its
> own workqueue instead of system workqueue. So if the cpu is busy
> processing the linkwatch event, it is not able to process other
> workqueue' work when the workqueue is scheduled on the same cpu.
> 
> Using unbound workqueue may solve the cpu starvation problem.
> But the __linkwatch_run_queue is called with rtnl_lock, so if it
> takes a lot time to process, other need to take the rtnl_lock may
> not be able to move forward.

Agree with the starvation issue. My cocern is that large number of
events that end up being delayed would impact things that are actually
watching for link events (like routing daemons).

It probably would be not accepted to do rtnl_unlock/sched_yield/rtnl_lock
in the loop, but that is another alternative.

Re: [PATCH] PM / devfreq: try_then_request_governor should not return NULL

2019-05-27 Thread Chanwoo Choi

Hi Rob,

You're right. It have to be posted to sta...@vger.kernel.org.
As you recommended, I send it[1] to sta...@vger.kernel.org for fixup.
[1]https://lkml.org/lkml/2019/5/27/547

Best Regards,
Chanwoo Choi

On 19. 5. 24. 오후 10:15, Rob Clark wrote:
> Ahh, thanks, I've not moved to the latest -rc yet..
> 
> That commit would be a good candidate for 5.1.y stable branch
> 
> BR,
> -R
> 
> On Fri, May 24, 2019 at 12:13 AM Chanwoo Choi  wrote:
>>
>> Hi,
>>
>> This issue[1] is already fixed on latest linux.git
>> You can check it. Thanks.
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b53b0128052ffd687797d5f4deeb76327e7b5711
>>
>> Regards,
>> Chanwoo Choi
>>
>>
>> On 19. 5. 24. 오전 6:58, Rob Clark wrote:
>>> From: Rob Clark 
>>>
>>> The two spots it is called expect either an IS_ERR() or a valid pointer,
>>> but not NULL.
>>>
>>> Fixes this crash that I came across:
>>>
>>>Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0030
>>>Mem abort info:
>>>  ESR = 0x9605
>>>  Exception class = DABT (current EL), IL = 32 bits
>>>  SET = 0, FnV = 0
>>>  EA = 0, S1PTW = 0
>>>Data abort info:
>>>  ISV = 0, ISS = 0x0005
>>>  CM = 0, WnR = 0
>>>[0030] user address but active_mm is swapper
>>>Internal error: Oops: 9605 [#1] PREEMPT SMP
>>>Modules linked in:
>>>Process kworker/2:1 (pid: 212, stack limit = 0x(ptrval))
>>>CPU: 2 PID: 212 Comm: kworker/2:1 Not tainted 
>>> 5.1.0-43338-g460e6984675c-dirty #54
>>>Hardware name: Google Cheza (rev3+) (DT)
>>>Workqueue: events deferred_probe_work_func
>>>pstate: 00c9 (nzcv daif +PAN +UAO)
>>>pc : devfreq_add_device+0x2e4/0x410
>>>lr : devfreq_add_device+0x2d4/0x410
>>>sp : ff8013d93740
>>>x29: ff8013d93790 x28: ffc0f54f8670
>>>x27: 0001 x26: 0007
>>>x25: ff80124abfd8 x24: 
>>>x23: ffc0fabc4048 x22: ffc0fabc4388
>>>x21: ffc0fabc4010 x20: ffc0fa243010
>>>x19: ffc0fabc4000 x18: 91c3d373
>>>x17: 0400 x16: 001a
>>>x15: 00019e06d400 x14: 0001
>>>x13:  x12: 06b6
>>>x11:  x10: 
>>>x9 : ffc0fa18ba00 x8 : 
>>>x7 :  x6 : ff80127a3d9a
>>>x5 : ff8013d93550 x4 : 
>>>x3 :  x2 : 
>>>x1 : 00fe x0 : 
>>>Call trace:
>>> devfreq_add_device+0x2e4/0x410
>>> devm_devfreq_add_device+0x64/0xac
>>> msm_gpu_init+0x320/0x5c0
>>> adreno_gpu_init+0x21c/0x274
>>> a6xx_gpu_init+0x68/0xf4
>>> adreno_bind+0x158/0x284
>>> component_bind_all+0x110/0x204
>>> msm_drm_bind+0x118/0x5b8
>>> try_to_bring_up_master+0x15c/0x19c
>>> component_master_add_with_match+0xb4/0xec
>>> msm_pdev_probe+0x1f0/0x27c
>>> platform_drv_probe+0x90/0xb0
>>> really_probe+0x120/0x298
>>> driver_probe_device+0x64/0xfc
>>> __device_attach_driver+0x8c/0xa4
>>> bus_for_each_drv+0x88/0xd0
>>> __device_attach+0xac/0x134
>>> device_initial_probe+0x20/0x2c
>>> bus_probe_device+0x34/0x90
>>> deferred_probe_work_func+0x74/0xac
>>> process_one_work+0x210/0x428
>>> worker_thread+0x278/0x3e4
>>> kthread+0x120/0x130
>>> ret_from_fork+0x10/0x18
>>>Code: aa0003f8 b13ffc1f 54000762 f901c278 (f9401b08)
>>>---[ end trace a6ecc18ce5894375 ]---
>>>Kernel panic - not syncing: Fatal exception
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  drivers/devfreq/devfreq.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index 0ae3de76833b..d29f66f0e52a 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -254,7 +254,7 @@ static struct devfreq_governor 
>>> *try_then_request_governor(const char *name)
>>>   /* Restore previous state before return */
>>>   mutex_lock(_list_lock);
>>>   if (err)
>>> - return NULL;
>>> + return ERR_PTR(err);
>>>
>>>   governor = find_devfreq_governor(name);
>>>   }
>>>
>>
>>
>> --
>> Best Regards,
>> Chanwoo Choi
>> Samsung Electronics
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v2] powerpc/power: Expose pfn_is_nosave prototype

"Rafael J. Wysocki"  writes:
> On Friday, May 24, 2019 12:44:18 PM CEST Mathieu Malaterre wrote:
>> The declaration for pfn_is_nosave is only available in
>> kernel/power/power.h. Since this function can be override in arch,
>> expose it globally. Having a prototype will make sure to avoid warning
>> (sometime treated as error with W=1) such as:
>> 
>>   arch/powerpc/kernel/suspend.c:18:5: error: no previous prototype for 
>> 'pfn_is_nosave' [-Werror=missing-prototypes]
>> 
>> This moves the declaration into a globally visible header file and add
>> missing include to avoid a warning on powerpc. Also remove the
>> duplicated prototypes since not required anymore.
>> 
>> Cc: Christophe Leroy 
>> Signed-off-by: Mathieu Malaterre 
>> ---
>> v2: As suggestion by christophe remove duplicates prototypes
>> 
>>  arch/powerpc/kernel/suspend.c | 1 +
>>  arch/s390/kernel/entry.h  | 1 -
>>  include/linux/suspend.h   | 1 +
>>  kernel/power/power.h  | 2 --
>>  4 files changed, 2 insertions(+), 3 deletions(-)
>> 
>> diff --git a/kernel/power/power.h b/kernel/power/power.h
>> index 9e58bdc8a562..44bee462ff57 100644
>> --- a/kernel/power/power.h
>> +++ b/kernel/power/power.h
>> @@ -75,8 +75,6 @@ static inline void hibernate_reserved_size_init(void) {}
>>  static inline void hibernate_image_size_init(void) {}
>>  #endif /* !CONFIG_HIBERNATION */
>>  
>> -extern int pfn_is_nosave(unsigned long);
>> -
>>  #define power_attr(_name) \
>>  static struct kobj_attribute _name##_attr = {   \
>>  .attr   = { \
>> 
>
> With an ACK from the powerpc maintainers, I could apply this one.

Sent.

cheers

Re: [PATCH v2] powerpc/power: Expose pfn_is_nosave prototype