[PATCH -next] perf/arm_dmc620_pmu: Fix error return code in dmc620_pmu_device_probe()
From: Wei Yongjun
Fix to return negative error code -ENOMEM from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 53c218da220c ("driver/perf: Add PMU driver for the ARM DMC-620 memory
controller")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/perf/arm_dmc620_pmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/perf/arm_dmc620_pmu.c b/drivers/perf/arm_dmc620_pmu.c
index 66ad5b3ece19..f2a85500258d 100644
--- a/drivers/perf/arm_dmc620_pmu.c
+++ b/drivers/perf/arm_dmc620_pmu.c
@@ -681,6 +681,7 @@ static int dmc620_pmu_device_probe(struct platform_device
*pdev)
if (!name) {
dev_err(>dev,
"Create name failed, PMU @%pa\n", >start);
+ ret = -ENOMEM;
goto out_teardown_dev;
}
[PATCH v2,4/5] media: mtk-vcodec: Add MT8192 H264 venc driver
Add MT8192 venc driver's compatible and device private data.
Signed-off-by: Irui Wang
---
.../media/platform/mtk-vcodec/mtk_vcodec_drv.h| 1 +
.../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 869d958d2b99..39e78aa670a3 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -302,6 +302,7 @@ struct mtk_vcodec_ctx {
enum mtk_chip {
MTK_MT8173,
MTK_MT8183,
+ MTK_MT8192,
};
/**
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 26b089e81213..981299a44c4a 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -425,12 +425,27 @@ static const struct mtk_vcodec_enc_pdata mt8183_pdata = {
.core_id = VENC_SYS,
};
+static const struct mtk_vcodec_enc_pdata mt8192_pdata = {
+ .chip = MTK_MT8192,
+ .uses_ext = true,
+ /* MT8192 supports the same capture formats as MT8183*/
+ .capture_formats = mtk_video_formats_capture_mt8183,
+ .num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_mt8183),
+ /* MT8192 supports the same output formats as MT8173 */
+ .output_formats = mtk_video_formats_output_mt8173,
+ .num_output_formats = ARRAY_SIZE(mtk_video_formats_output_mt8173),
+ .min_bitrate = 64,
+ .max_bitrate = 1,
+ .core_id = VENC_SYS,
+};
+
static const struct of_device_id mtk_vcodec_enc_match[] = {
{.compatible = "mediatek,mt8173-vcodec-enc",
.data = _avc_pdata},
{.compatible = "mediatek,mt8173-vcodec-enc-vp8",
.data = _vp8_pdata},
{.compatible = "mediatek,mt8183-vcodec-enc", .data = _pdata},
+ {.compatible = "mediatek,mt8192-vcodec-enc", .data = _pdata},
{},
};
MODULE_DEVICE_TABLE(of, mtk_vcodec_enc_match);
--
2.18.0
[PATCH v2,5/5] media: mtk-vcodec: Support H264 4K encoding on MT8192
Supports H264 4K (3840x2176) and level 5.1 encoding on MT8192.
Signed-off-by: Irui Wang
---
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 58 ++-
.../platform/mtk-vcodec/venc/venc_h264_if.c | 4 ++
2 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 4831052f475d..707db06abf9b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -21,12 +21,16 @@
#define MTK_VENC_MIN_H 128U
#define MTK_VENC_MAX_W 1920U
#define MTK_VENC_MAX_H 1088U
+#define MTK_VENC_4K_MAX_W 3840U
+#define MTK_VENC_4K_MAX_H 2176U
+
#define DFT_CFG_WIDTH MTK_VENC_MIN_W
#define DFT_CFG_HEIGHT MTK_VENC_MIN_H
#define MTK_MAX_CTRLS_HINT 20
#define MTK_DEFAULT_FRAMERATE_NUM 1001
#define MTK_DEFAULT_FRAMERATE_DENOM 3
+#define MTK_VENC_4K_CAPABILITY_ENABLE BIT(0)
static void mtk_venc_worker(struct work_struct *work);
@@ -151,18 +155,23 @@ static int vidioc_enum_framesizes(struct file *file, void
*fh,
struct v4l2_frmsizeenum *fsize)
{
const struct mtk_video_fmt *fmt;
+ struct mtk_vcodec_ctx *ctx = fh_to_ctx(fh);
if (fsize->index != 0)
return -EINVAL;
fmt = mtk_venc_find_format(fsize->pixel_format,
- fh_to_ctx(fh)->dev->venc_pdata);
+ ctx->dev->venc_pdata);
if (!fmt)
return -EINVAL;
fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
fsize->stepwise = mtk_venc_framesizes;
+ if (ctx->dev->enc_capability & MTK_VENC_4K_CAPABILITY_ENABLE) {
+ fsize->stepwise.max_width = MTK_VENC_4K_MAX_W;
+ fsize->stepwise.max_height = MTK_VENC_4K_MAX_H;
+ }
return 0;
}
@@ -248,7 +257,7 @@ static struct mtk_q_data *mtk_venc_get_q_data(struct
mtk_vcodec_ctx *ctx,
/* V4L2 specification suggests the driver corrects the format struct if any of
* the dimensions is unsupported
*/
-static int vidioc_try_fmt(struct v4l2_format *f,
+static int vidioc_try_fmt(struct mtk_vcodec_ctx *ctx, struct v4l2_format *f,
const struct mtk_video_fmt *fmt)
{
struct v4l2_pix_format_mplane *pix_fmt_mp = >fmt.pix_mp;
@@ -260,13 +269,22 @@ static int vidioc_try_fmt(struct v4l2_format *f,
pix_fmt_mp->plane_fmt[0].bytesperline = 0;
} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
int tmp_w, tmp_h;
+ unsigned int max_width, max_height;
+
+ if (ctx->dev->enc_capability & MTK_VENC_4K_CAPABILITY_ENABLE) {
+ max_width = MTK_VENC_4K_MAX_W;
+ max_height = MTK_VENC_4K_MAX_H;
+ } else {
+ max_width = MTK_VENC_MAX_W;
+ max_height = MTK_VENC_MAX_H;
+ }
pix_fmt_mp->height = clamp(pix_fmt_mp->height,
MTK_VENC_MIN_H,
- MTK_VENC_MAX_H);
+ max_height);
pix_fmt_mp->width = clamp(pix_fmt_mp->width,
MTK_VENC_MIN_W,
- MTK_VENC_MAX_W);
+ max_width);
/* find next closer width align 16, heign align 32, size align
* 64 rectangle
@@ -275,16 +293,16 @@ static int vidioc_try_fmt(struct v4l2_format *f,
tmp_h = pix_fmt_mp->height;
v4l_bound_align_image(_fmt_mp->width,
MTK_VENC_MIN_W,
- MTK_VENC_MAX_W, 4,
+ max_width, 4,
_fmt_mp->height,
MTK_VENC_MIN_H,
- MTK_VENC_MAX_H, 5, 6);
+ max_height, 5, 6);
if (pix_fmt_mp->width < tmp_w &&
- (pix_fmt_mp->width + 16) <= MTK_VENC_MAX_W)
+ (pix_fmt_mp->width + 16) <= max_width)
pix_fmt_mp->width += 16;
if (pix_fmt_mp->height < tmp_h &&
- (pix_fmt_mp->height + 32) <= MTK_VENC_MAX_H)
+ (pix_fmt_mp->height + 32) <= max_height)
pix_fmt_mp->height += 32;
mtk_v4l2_debug(0,
@@ -405,7 +423,7 @@ static int vidioc_venc_s_fmt_cap(struct file *file, void
*priv,
}
q_data->fmt = fmt;
- ret = vidioc_try_fmt(f, q_data->fmt);
+ ret = vidioc_try_fmt(ctx, f, q_data->fmt);
if (ret)
return ret;
@@ -478,7 +496,7 @@ static int vidioc_venc_s_fmt_out(struct file *file, void
*priv,
[PATCH v2,2/5] media: mtk-vcodec: Support 4GB~8GB range iova space for venc
Uses the dma_set_mask_and_coherent helper to set venc
DMA bit mask to support 4GB~8GB range iova space.
Signed-off-by: Irui Wang
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 3 +++
1 file changed, 3 insertions(+)
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 7d7b8cfc2cc5..26b089e81213 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -361,6 +361,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_event_workq;
}
+ if (of_get_property(pdev->dev.of_node, "dma-ranges", NULL))
+ dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(34));
+
ret = video_register_device(vfd_enc, VFL_TYPE_VIDEO, 1);
if (ret) {
mtk_v4l2_err("Failed to register video device");
--
2.18.0
[PATCH v2,0/5] Support H264 4K on MT8192
Add MT8192 H264 venc driver and support H264 4K encoding on MT8192. Signed-off-by: Irui Wang --- This patch dependents on "dt-bindings: media: mtk-vcodec: Separating mtk vcodec encoder node" [1] We need "core_id" variable in device private data to indicate current encoder driver. Please also accept this patch together with [1]. http://lists.infradead.org/pipermail/linux-mediatek/2021-March/022432.html --- Change since v1: - remove encoder device tree example in dt-bindings --- Irui Wang (5): dt-bindings: media: mtk-vcodec: Add dma-ranges property media: mtk-vcodec: Support 4GB~8GB range iova space for venc dt-bindings: media: mtk-vcodec: Add binding for MT8192 VENC media: mtk-vcodec: Add MT8192 H264 venc driver media: mtk-vcodec: Support H264 4K encoding on MT8192 .../bindings/media/mediatek-vcodec.txt| 3 + .../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 + .../platform/mtk-vcodec/mtk_vcodec_enc.c | 58 ++- .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 18 ++ .../platform/mtk-vcodec/venc/venc_h264_if.c | 4 ++ 5 files changed, 69 insertions(+), 15 deletions(-) -- 2.18.0
[PATCH v2,3/5] dt-bindings: media: mtk-vcodec: Add binding for MT8192 VENC
Updates binding document for mt8192 encoder driver. Signed-off-by: Irui Wang --- Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt index d852683d3e6f..8f196f2d6905 100644 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt @@ -9,6 +9,7 @@ Required properties: "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder. "mediatek,mt8183-vcodec-enc" for MT8183 encoder. "mediatek,mt8173-vcodec-dec" for MT8173 decoder. + "mediatek,mt8192-vcodec-enc" for MT8192 encoder. - reg : Physical base address of the video codec registers and length of memory mapped region. - interrupts : interrupt number to the cpu. -- 2.18.0
[PATCH v2,1/5] dt-bindings: media: mtk-vcodec: Add dma-ranges property
The mt8192 iommu support 0~16GB iova. We separate it to four banks: 0~4G; 4G~8G; 8G~12G; 12G~16G. The "dma-ranges" could be used to adjust the bank we locate. If we don't set this property. The default range always is 0~4G. Here we don't have actual bus/parent concept here. And the iova requirement is for our HW. Thus put the property in our node. Signed-off-by: Irui Wang --- Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt index 8318f0ed492d..d852683d3e6f 100644 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt @@ -22,6 +22,8 @@ Required properties: - iommus : should point to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt for details. +- dma-ranges : describes how the physical address space of the IOMMU maps + to memory. One of the two following nodes: - mediatek,vpu : the node of the video processor unit, if using VPU. - mediatek,scp : the node of the SCP unit, if using SCP. -- 2.18.0
[PATCH] ia64: tools: add generic errno.h definition
Noticed missing header when build bpfilter helper: CC [U] net/bpfilter/main.o In file included from /usr/include/linux/errno.h:1, from /usr/include/bits/errno.h:26, from /usr/include/errno.h:28, from net/bpfilter/main.c:4: tools/include/uapi/asm/errno.h:13:10: fatal error: ../../../arch/ia64/include/uapi/asm/errno.h: No such file or directory 13 | #include "../../../arch/ia64/include/uapi/asm/errno.h" | ^ CC: linux-kernel@vger.kernel.org CC: net...@vger.kernel.org CC: b...@vger.kernel.org Signed-off-by: Sergei Trofimovich --- tools/arch/ia64/include/uapi/asm/errno.h | 1 + 1 file changed, 1 insertion(+) create mode 100644 tools/arch/ia64/include/uapi/asm/errno.h diff --git a/tools/arch/ia64/include/uapi/asm/errno.h b/tools/arch/ia64/include/uapi/asm/errno.h new file mode 100644 index ..4c82b503d92f --- /dev/null +++ b/tools/arch/ia64/include/uapi/asm/errno.h @@ -0,0 +1 @@ +#include -- 2.30.2
Re: [PATCH v7] i2c: virtio: add a virtio i2c frontend driver
On 2021/3/12 14:10, Viresh Kumar wrote:
I saw your email about wrong version being sent, I already wrote some
reviews. Sending them anyway for FWIW :)
On 12-03-21, 21:33, Jie Deng wrote:
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct mutex lock;
As I said in the previous version (Yes, we were both waiting for
Wolfram to answer that), this lock shouldn't be required at all.
And since none of us have a use-case at hand where we will have a
problem without this lock, we should really skip it. We can always
come back and add it if we find an issue somewhere. Until then, better
to keep it simple.
The problem is you can't guarantee that adap->algo->master_xfer
is only called from i2c_transfer. Any function who holds the adapter can
call
adap->algo->master_xfer directly. I prefer to avoid potential issues
rather than
find a issue then fix.
+
+static struct i2c_adapter virtio_adapter = {
+ .owner = THIS_MODULE,
+ .name = "Virtio I2C Adapter",
+ .class = I2C_CLASS_DEPRECATED,
What happened to this discussion ?
https://lore.kernel.org/lkml/20210305072903.wtw645rukmqr5hx5@vireshk-i7/
My understanding is that new driver sets this to warn users that the
adapter doesn't support classes anymore.
I'm not sure if Wolfram can explain it more clear for you.
+ .algo = _algorithm,
+
+ return ret;
+
+ vi->adap = virtio_adapter;
This is strange, why are you allocating memory for adapter twice ?
Once for virtio_adapter and once for vi->adap ? Either fill the fields
directly for v->adap here and remove virtio_adapter or make vi->adap a
pointer.
Will make vi->adap a pointer. Thanks.
回复: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report
发件人: Dmitry Vyukov
发送时间: 2021年3月12日 14:30
收件人: Zhang, Qiang
抄送: Russell King - ARM Linux; Andrew Morton; LKML; Linux ARM; syzkaller-bugs
主题: Re: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Fri, Mar 12, 2021 at 5:13 AM wrote:
>
> From: Zqiang
>
> BUG: using smp_processor_id() in preemptible [] code:
> syz-executor.0/15841
> caller is debug_smp_processor_id+0x20/0x24
> lib/smp_processor_id.c:64
>
> The smp_processor_id() is used in a code segment when
> preemption has been disabled, otherwise, when preemption
> is enabled this pointer is usually no longer useful
> since it may no longer point to per cpu data of the
> current processor.
>
> Reported-by: syzbot
> Fixes: f5fe12b1eaee ("ARM: spectre-v2: harden user aborts in kernel space")
> Signed-off-by: Zqiang
> ---
> arch/arm/include/asm/system_misc.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/include/asm/system_misc.h
> b/arch/arm/include/asm/system_misc.h
> index 66f6a3ae68d2..61916dc7d361 100644
> --- a/arch/arm/include/asm/system_misc.h
> +++ b/arch/arm/include/asm/system_misc.h
> @@ -21,8 +21,10 @@ typedef void (*harden_branch_predictor_fn_t)(void);
> DECLARE_PER_CPU(harden_branch_predictor_fn_t, harden_branch_predictor_fn);
> static inline void harden_branch_predictor(void)
> {
> + preempt_disable();
> harden_branch_predictor_fn_t fn = per_cpu(harden_branch_predictor_fn,
> smp_processor_id());
> + preempt_enable();
> if (fn)
> fn();
> }
>Hi Qiang,
>
>If the CPU can change here, what if it changes right after >preempt_enable()?
>Disabling preemption just around reading the callback looks like a
>no-op. Shouldn't we disable preemption at least around reading and
>calling the callback?
Hi dvyukov
Oh, I'm confused, we should call preempt_enable after calling callback
function, to make sure callback function is called on current processor .
thank you for your remind.
>
>On the second look, the fn seems to be const after init, so maybe we
>need to use raw_smp_processor_id() instead with an explanatory
>comment?
[syzbot] WARNING in __i2c_transfer
Hello, syzbot found the following issue on: HEAD commit:28806e4d Merge tag 'media/v5.12-2' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11192342d0 kernel config: https://syzkaller.appspot.com/x/.config?x=6bcf96204c1b8e77 dashboard link: https://syzkaller.appspot.com/bug?extid=ffb0b3ffa6cfbc7d7b3f syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1083223ad0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14345f0ad0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+ffb0b3ffa6cfbc7d7...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 8406 at drivers/i2c/i2c-core-base.c:2021 __i2c_transfer+0xa87/0x17d0 drivers/i2c/i2c-core-base.c:2021 Modules linked in: CPU: 0 PID: 8406 Comm: syz-executor613 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__i2c_transfer+0xa87/0x17d0 drivers/i2c/i2c-core-base.c:2021 Code: 0f 94 c7 31 ff 44 89 fe e8 96 ba c2 fb 45 84 ff 0f 84 b3 fc ff ff e8 d8 b3 c2 fb e8 b2 5a 4f fb e9 a4 fc ff ff e8 c9 b3 c2 fb <0f> 0b 41 bc ea ff ff ff e9 2b fd ff ff e8 b7 b3 c2 fb 44 89 ee bf RSP: 0018:c900018cfd48 EFLAGS: 00010293 RAX: RBX: 0010 RCX: RDX: 88801e4e5340 RSI: 85b0ea97 RDI: 0003 RBP: 888020870b58 R08: R09: 8faa792f R10: 85b0e048 R11: 11ed6964 R12: 0010 R13: R14: 888020870b78 R15: FS: 0226f300() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f5096c0 CR3: 12e13000 CR4: 00350ef0 Call Trace: i2c_transfer+0x1e6/0x3e0 drivers/i2c/i2c-core-base.c:2112 i2cdev_ioctl_rdwr+0x583/0x6a0 drivers/i2c/i2c-dev.c:297 i2cdev_ioctl+0x46c/0x780 drivers/i2c/i2c-dev.c:453 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x443469 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fffb0c53048 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 004004a0 RCX: 00443469 RDX: 20004480 RSI: 0707 RDI: 0003 RBP: 00403010 R08: 00232d6332692f76 R09: 004004a0 R10: 001f R11: 0246 R12: 004030a0 R13: R14: 004b1018 R15: 004004a0 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH RESEND v3 0/5] media: uvcvideo: Fix race conditions
Hi, Guenter Roeck wrote on Thu, Sep 17, 2020 at 07:16:17PM -0700: > On 9/17/20 5:47 AM, Laurent Pinchart wrote: > > On Wed, Sep 16, 2020 at 07:25:42PM -0700, Guenter Roeck wrote: > >> Something seems to have gone wrong with v3 of this patch series. > >> I am sure I sent it out, but I don't find it anywhere. > >> Resending. Sorry for any duplicates. > > > > I haven't checked the mailing list, but I've found it in my inbox :-) > > I'm not forgetting about you, just been fairly busy recently. I still > > plan to try and provide an alternative implementation in the V4L2 core > > (in a form that I think should even be moved to the cdev core) that > > would fix this for all drivers. > > > Thanks for letting me know. As it turns out, this problem is responsible > for about 2% of all Chromebook crashes, so I'll probably not wait for > the series to be accepted upstream but apply it as-is to the various > ChromeOS kernel branches. We have a customer who reported the same issue recently, has there been any development? I don't see anything in either uvc nor v4l2 that would address the race since this mail half a year ago (well, I could have missed it ;)) If nothing happened I'll probably backport this series as well, at which point it might make more sense to take it in until a better fix gets here then revert it... Thanks! -- Dominique
[PATCH 1/2] crypto: qat - dont release uninitialized resources
adf_vf_isr_resource_alloc() is not unwinding correctly when error happens and it trys to release uninitialized resources. To fix this, only release initialized resources. [1.792594] [ cut here ] [1.792845] Trying to free already-free IRQ 11 [1.793091] WARNING: CPU: 0 PID: 182 at kernel/irq/manage.c:1821 free_irq+0x202/0x380 [1.793518] Modules linked in: qat_c3xxxvf(+) drm snd_pcm intel_qat snd_timer snd joydev psmouse 4 [1.794998] CPU: 0 PID: 182 Comm: systemd-udevd Not tainted 5.12.0-rc2+ #78 [1.795379] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [1.795986] RIP: 0010:free_irq+0x202/0x380 [1.796211] Code: e8 23 6a 1b 00 48 83 c4 10 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 8b 75 d0 40 [1.797215] RSP: 0018:c9ce3970 EFLAGS: 00010082 [1.797500] RAX: RBX: 888104b75200 RCX: 0027 [1.797886] RDX: 0027 RSI: dfff RDI: 88817bc18448 [1.798270] RBP: c9ce39a8 R08: 88817bc18440 R09: c9ce3730 [1.798655] R10: 0001 R11: 0001 R12: 8881001c2200 [1.799040] R13: 8881001c2360 R14: 8881001c22a4 R15: 8881008b30c8 [1.799434] FS: 7f2313cd38c0() GS:88817bc0() knlGS: [1.799871] CS: 0010 DS: ES: CR0: 80050033 [1.800183] CR2: 7ffc6f4b4080 CR3: 000104a3c000 CR4: 06f0 [1.800569] DR0: DR1: DR2: [1.800954] DR3: DR6: fffe0ff0 DR7: 0400 [1.801340] Call Trace: [1.801477] adf_vf_isr_resource_free+0x32/0xb0 [intel_qat] [1.801785] adf_vf_isr_resource_alloc+0x14d/0x150 [intel_qat] [1.802105] adf_dev_init+0xba/0x140 [intel_qat] [1.802365] adf_probe+0x32f/0x370 [qat_c3xxxvf] [1.802620] local_pci_probe+0x48/0x80 [1.802827] pci_device_probe+0x10f/0x1c0 [1.803048] really_probe+0xfb/0x420 [1.803249] driver_probe_device+0xe9/0x160 [1.803479] device_driver_attach+0x5d/0x70 [1.803709] __driver_attach+0x8f/0x150 [1.803920] ? device_driver_attach+0x70/0x70 [1.804159] bus_for_each_dev+0x7e/0xc0 [1.804370] driver_attach+0x1e/0x20 [1.804568] bus_add_driver+0x152/0x1f0 [1.804779] driver_register+0x74/0xd0 [1.804986] ? 0xc009b000 [1.805169] __pci_register_driver+0x54/0x60 [1.805404] adfdrv_init+0x34/0x1000 [qat_c3xxxvf] [1.805667] do_one_initcall+0x48/0x1d0 [1.805879] ? __slab_alloc+0x20/0x40 [1.806081] ? kmem_cache_alloc_trace+0x390/0x440 [1.806338] ? do_init_module+0x28/0x250 [1.806555] do_init_module+0x62/0x250 [1.806762] load_module+0x23ee/0x26a0 [1.806970] __do_sys_finit_module+0xc2/0x120 [1.807211] ? __do_sys_finit_module+0xc2/0x120 [1.807460] __x64_sys_finit_module+0x1a/0x20 [1.807693] do_syscall_64+0x38/0x90 [1.807892] entry_SYSCALL_64_after_hwframe+0x44/0xae [1.808167] RIP: 0033:0x7f2312b50469 [1.808365] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 [1.809368] RSP: 002b:7ffeae1d29e8 EFLAGS: 0246 ORIG_RAX: 0139 [1.809775] RAX: ffda RBX: 55909ee6aee0 RCX: 7f2312b50469 [1.810159] RDX: RSI: 7f2313469265 RDI: 0010 [1.810543] RBP: 7f2313469265 R08: R09: 7ffeae1d2f60 [1.810927] R10: 0010 R11: 0246 R12: [1.811312] R13: 55909ee6afe0 R14: 0002 R15: 55909dd2fefc [1.811697] ---[ end trace ff698e93b7952e56 ]--- [1.811962] BUG: unable to handle page fault for address: ebde03c8 [1.812341] #PF: supervisor read access in kernel mode [1.812621] #PF: error_code(0x) - not-present page [1.812902] PGD 0 P4D 0 [1.813044] Oops: [#1] SMP NOPTI [1.813246] CPU: 0 PID: 182 Comm: systemd-udevd Tainted: GW 5.12.0-rc2+ #78 [1.813697] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [1.814302] RIP: 0010:kfree+0x5d/0x420 [1.814508] Code: db 4d 01 fd 0f 82 c8 03 00 00 49 c7 c4 00 00 00 80 4c 2b 25 e5 f1 1c 01 4d 01 ed [1.815518] RSP: 0018:c9ce3970 EFLAGS: 00010286 [1.815803] RAX: 1401 RBX: RCX: [1.816189] RDX: 8881047291b0 RSI: c01a72cf RDI: f000 [1.816575] RBP: c9ce39a8 R08: 88817bc18440 R09: 0246 [1.816961] R10: 0001 R11: 0001 R12: ebde03c0 [1.817348] R13: 8000f000 R14: R15: f000 [1.817734] FS: 7f2313cd38c0() GS:88817bc0() knlGS: [1.818170] CS: 0010 DS: ES: CR0: 80050033 [1.818483] CR2:
[PATCH 2/2] crypto: qat: ADF_STATUS_PF_RUNNING should be set after adf_dev_init
ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [7.178008] == [7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [7.178800] Read of size 4 at addr f434 by task modprobe/96 [7.179169] [7.179257] CPU: 0 PID: 96 Comm: modprobe Not tainted 5.12.0-rc2-00338-gf78d76e72a46-dirty #86 [7.179730] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-4 [7.180345] Call Trace: [7.180485] dump_stack+0x8a/0xb5 [7.180676] kasan_report.cold+0x10f/0x111 [7.180907] ? __mutex_lock.isra.0+0x1ac/0x7c0 [7.181156] __mutex_lock.isra.0+0x1ac/0x7c0 [7.181394] ? finish_task_switch+0x12f/0x360 [7.181640] ? __switch_to+0x339/0x6b0 [7.181852] ? ww_mutex_lock_interruptible+0x150/0x150 [7.182138] ? __sched_text_start+0x8/0x8 [7.182363] ? vprintk_emit+0x91/0x170 [7.182576] mutex_lock+0xc9/0xd0 [7.182765] ? __mutex_lock_slowpath+0x10/0x10 [7.183016] ? swsusp_write.cold+0x208/0x208 [7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf] [7.184403] ? adf_remove+0x70/0x70 [qat_dh895xccvf] [7.184681] ? _raw_spin_lock_irqsave+0x7b/0xd0 [7.184936] ? _raw_spin_unlock_irqrestore+0xd/0x20 [7.185209] ? adf_remove+0x70/0x70 [qat_dh895xccvf] [7.185489] local_pci_probe+0x6f/0xb0 [7.185702] pci_device_probe+0x1e9/0x2f0 [7.185928] ? pci_device_remove+0xf0/0xf0 [7.186159] ? sysfs_do_create_link_sd.isra.0+0x76/0xe0 [7.186458] really_probe+0x161/0x420 [7.186665] driver_probe_device+0x6d/0xd0 [7.186894] device_driver_attach+0x82/0x90 [7.187131] ? device_driver_attach+0x90/0x90 [7.187375] __driver_attach+0x60/0x100 [7.187591] ? device_driver_attach+0x90/0x90 [7.187835] bus_for_each_dev+0xe1/0x140 [7.188057] ? subsys_dev_iter_exit+0x10/0x10 [7.188302] ? klist_node_init+0x61/0x80 [7.188524] bus_add_driver+0x254/0x2a0 [7.188740] driver_register+0xd3/0x150 [7.188956] ? 0xc005 [7.189143] adfdrv_init+0x2b/0x1000 [qat_dh895xccvf] [7.189427] do_one_initcall+0x84/0x250 [7.189644] ? trace_event_raw_event_initcall_finish+0x150/0x150 [7.189977] ? _raw_spin_unlock_irqrestore+0xd/0x20 [7.190250] ? create_object+0x395/0x510 [7.190472] ? kasan_unpoison+0x21/0x50 [7.190689] do_init_module+0xf8/0x350 [7.190901] load_module+0x40c5/0x4410 [7.191121] ? module_frob_arch_sections+0x20/0x20 [7.191390] ? kernel_read_file+0x1cd/0x3e0 [7.191626] ? __do_sys_finit_module+0x108/0x170 [7.191885] __do_sys_finit_module+0x108/0x170 [7.192134] ? __ia32_sys_init_module+0x40/0x40 [7.192389] ? file_open_root+0x200/0x200 [7.192615] ? do_sys_open+0x85/0xe0 [7.192817] ? filp_open+0x50/0x50 [7.193010] ? exit_to_user_mode_prepare+0xfc/0x130 [7.193283] do_syscall_64+0x33/0x40 [7.193486] entry_SYSCALL_64_after_hwframe+0x44/0xae [7.193770] RIP: 0033:0x7f6ad21b4cf7 [7.193971] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 41 [7.194991] RSP: 002b:7ffe2a5d9028 EFLAGS: 0246 ORIG_RAX: 0139 [7.195408] RAX: ffda RBX: 00882a70 RCX: 7f6ad21b4cf7 [7.195801] RDX: RSI: 008819e0 RDI: 0003 [7.196193] RBP: 0003 R08: R09: 0001 [7.196588] R10: 7f6ad2218300 R11: 0246 R12: 008819e0 [7.196979] R13: R14: 00881dd0 R15: 0001 [7.197372] == Signed-off-by: Tong Zhang --- drivers/crypto/qat/qat_c3xxxvf/adf_drv.c| 4 ++-- drivers/crypto/qat/qat_c62xvf/adf_drv.c | 4 ++-- drivers/crypto/qat/qat_dh895xccvf/adf_drv.c | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c b/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c index 1d1532e8fb6d..067ca5e17d38 100644 --- a/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c +++ b/drivers/crypto/qat/qat_c3xxxvf/adf_drv.c @@ -184,12 +184,12 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto out_err_free_reg; - set_bit(ADF_STATUS_PF_RUNNING, _dev->status); - ret = adf_dev_init(accel_dev); if (ret)
[PATCH 0/2] crypto: qat: fix couple crashes duing error handling
There are a couple of issues in qat error handling. Those drivers tries to release resources that is not initialized. This patch series tries to fix crashes caused by incorrect error handling. Tong Zhang (2): crypto: qat - dont release uninitialized resources crypto: qat: ADF_STATUS_PF_RUNNING should be set after adf_dev_init drivers/crypto/qat/qat_c3xxxvf/adf_drv.c| 4 ++-- drivers/crypto/qat/qat_c62xvf/adf_drv.c | 4 ++-- drivers/crypto/qat/qat_common/adf_vf_isr.c | 17 + drivers/crypto/qat/qat_dh895xccvf/adf_drv.c | 4 ++-- 4 files changed, 19 insertions(+), 10 deletions(-) -- 2.25.1
[PATCH] regulator: bd9576: Fix return from bd957x_probe()
The probe() function returns an uninitialized variable in the success
path. There is no need for the "err" variable at all, just delete it.
Fixes: b014e9fae7e7 ("regulator: Support ROHM BD9576MUF and BD9573MUF")
Signed-off-by: Dan Carpenter
---
drivers/regulator/bd9576-regulator.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/bd9576-regulator.c
b/drivers/regulator/bd9576-regulator.c
index a8b5832a5a1b..204a2da054f5 100644
--- a/drivers/regulator/bd9576-regulator.c
+++ b/drivers/regulator/bd9576-regulator.c
@@ -206,7 +206,7 @@ static int bd957x_probe(struct platform_device *pdev)
{
struct regmap *regmap;
struct regulator_config config = { 0 };
- int i, err;
+ int i;
bool vout_mode, ddr_sel;
const struct bd957x_regulator_data *reg_data = _regulators[0];
unsigned int num_reg_data = ARRAY_SIZE(bd9576_regulators);
@@ -279,8 +279,7 @@ static int bd957x_probe(struct platform_device *pdev)
break;
default:
dev_err(>dev, "Unsupported chip type\n");
- err = -EINVAL;
- goto err;
+ return -EINVAL;
}
config.dev = pdev->dev.parent;
@@ -300,8 +299,7 @@ static int bd957x_probe(struct platform_device *pdev)
dev_err(>dev,
"failed to register %s regulator\n",
desc->name);
- err = PTR_ERR(rdev);
- goto err;
+ return PTR_ERR(rdev);
}
/*
* Clear the VOUT1 GPIO setting - rest of the regulators do not
@@ -310,8 +308,7 @@ static int bd957x_probe(struct platform_device *pdev)
config.ena_gpiod = NULL;
}
-err:
- return err;
+ return 0;
}
static const struct platform_device_id bd957x_pmic_id[] = {
--
2.30.1
[v3,PATCH 3/3] media: mtk-vcodec: Separating mtk encoder driver
MTK H264 Encoder(VENC_SYS) and VP8 Encoder(VENC_LT_SYS) are two
independent hardware instance. They have their owner interrupt,
register mapping, and special clocks.
This patch separates them into two devices. This is a preparing
patch for adding device_link between the larbs and venc-device.
It's mainly for fixing the problem:
https://lkml.org/lkml/2019/9/3/316
Acked-by: Tiffany Lin
Signed-off-by: Hsin-Yi Wang
Signed-off-by: Maoguang Meng
Signed-off-by: Irui Wang
---
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 7 +-
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 18 ++-
.../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 108 +++---
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 40 +--
.../platform/mtk-vcodec/venc/venc_vp8_if.c| 4 +-
5 files changed, 67 insertions(+), 110 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 3dd010cba23e..869d958d2b99 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -193,7 +193,6 @@ struct mtk_vcodec_pm {
struct mtk_vcodec_clk venc_clk;
struct device *larbvenc;
- struct device *larbvenclt;
struct device *dev;
struct mtk_vcodec_dev *mtkdev;
};
@@ -311,25 +310,25 @@ enum mtk_chip {
* @chip: chip this encoder is compatible with
*
* @uses_ext: whether the encoder uses the extended firmware messaging format
- * @has_lt_irq: whether the encoder uses the LT irq
* @min_birate: minimum supported encoding bitrate
* @max_bitrate: maximum supported encoding bitrate
* @capture_formats: array of supported capture formats
* @num_capture_formats: number of entries in capture_formats
* @output_formats: array of supported output formats
* @num_output_formats: number of entries in output_formats
+ * @core_id: stand for h264 or vp8 encode index
*/
struct mtk_vcodec_enc_pdata {
enum mtk_chip chip;
bool uses_ext;
- bool has_lt_irq;
unsigned long min_bitrate;
unsigned long max_bitrate;
const struct mtk_video_fmt *capture_formats;
size_t num_capture_formats;
const struct mtk_video_fmt *output_formats;
size_t num_output_formats;
+ int core_id;
};
#define MTK_ENC_CTX_IS_EXT(ctx) ((ctx)->dev->venc_pdata->uses_ext)
@@ -361,7 +360,6 @@ struct mtk_vcodec_enc_pdata {
*
* @dec_irq: decoder irq resource
* @enc_irq: h264 encoder irq resource
- * @enc_lt_irq: vp8 encoder irq resource
*
* @dec_mutex: decoder hardware lock
* @enc_mutex: encoder hardware lock.
@@ -397,7 +395,6 @@ struct mtk_vcodec_dev {
int dec_irq;
int enc_irq;
- int enc_lt_irq;
struct mutex dec_mutex;
struct mutex enc_mutex;
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 8c917969c2f1..4831052f475d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "mtk_vcodec_drv.h"
#include "mtk_vcodec_enc.h"
@@ -787,7 +788,7 @@ static int vb2ops_venc_start_streaming(struct vb2_queue *q,
unsigned int count)
*/
if ((ctx->state == MTK_STATE_ABORT) || (ctx->state == MTK_STATE_FREE)) {
ret = -EIO;
- goto err_set_param;
+ goto err_start_stream;
}
/* Do the initialization when both start_streaming have been called */
@@ -799,6 +800,12 @@ static int vb2ops_venc_start_streaming(struct vb2_queue
*q, unsigned int count)
return 0;
}
+ ret = pm_runtime_resume_and_get(>dev->plat_dev->dev);
+ if (ret < 0) {
+ mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
+ goto err_start_stream;
+ }
+
mtk_venc_set_param(ctx, );
ret = venc_if_set_param(ctx, VENC_SET_PARAM_ENC, );
if (ret) {
@@ -825,6 +832,11 @@ static int vb2ops_venc_start_streaming(struct vb2_queue
*q, unsigned int count)
return 0;
err_set_param:
+ ret = pm_runtime_put(>dev->plat_dev->dev);
+ if (ret < 0)
+ mtk_v4l2_err("pm_runtime_put fail %d", ret);
+
+err_start_stream:
for (i = 0; i < q->num_buffers; ++i) {
struct vb2_buffer *buf = vb2_get_buffer(q, i);
@@ -878,6 +890,10 @@ static void vb2ops_venc_stop_streaming(struct vb2_queue *q)
if (ret)
mtk_v4l2_err("venc_if_deinit failed=%d", ret);
+ ret = pm_runtime_put(>dev->plat_dev->dev);
+ if (ret < 0)
+ mtk_v4l2_err("pm_runtime_put fail %d", ret);
+
ctx->state = MTK_STATE_FREE;
}
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 be3842e6ca47..7d7b8cfc2cc5 100644
[v3,PATCH 2/3] arm64: dts: mt8173: Separating mtk-vcodec-enc device node
There are two separate hardware encoder blocks inside MT8173.
Split the current mtk-vcodec-enc node to match the hardware architecture.
Acked-by: Tiffany Lin
Signed-off-by: Hsin-Yi Wang
Signed-off-by: Maoguang Meng
Signed-off-by: Irui Wang
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 60
1 file changed, 31 insertions(+), 29 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 7fa870e4386a..f5950e9fc51d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1458,14 +1458,11 @@
clock-names = "apb", "smi";
};
- vcodec_enc: vcodec@18002000 {
+ vcodec_enc_avc: vcodec@18002000 {
compatible = "mediatek,mt8173-vcodec-enc";
- reg = <0 0x18002000 0 0x1000>, /* VENC_SYS */
- <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
- interrupts = ,
-;
- mediatek,larb = <>,
- <>;
+ reg = <0 0x18002000 0 0x1000>; /* VENC_SYS */
+ interrupts = ;
+ mediatek,larb = <>;
iommus = < M4U_PORT_VENC_RCPU>,
< M4U_PORT_VENC_REC>,
< M4U_PORT_VENC_BSDMA>,
@@ -1476,29 +1473,12 @@
< M4U_PORT_VENC_REF_LUMA>,
< M4U_PORT_VENC_REF_CHROMA>,
< M4U_PORT_VENC_NBM_RDMA>,
-< M4U_PORT_VENC_NBM_WDMA>,
-< M4U_PORT_VENC_RCPU_SET2>,
-< M4U_PORT_VENC_REC_FRM_SET2>,
-< M4U_PORT_VENC_BSDMA_SET2>,
-< M4U_PORT_VENC_SV_COMA_SET2>,
-< M4U_PORT_VENC_RD_COMA_SET2>,
-< M4U_PORT_VENC_CUR_LUMA_SET2>,
-< M4U_PORT_VENC_CUR_CHROMA_SET2>,
-< M4U_PORT_VENC_REF_LUMA_SET2>,
-< M4U_PORT_VENC_REC_CHROMA_SET2>;
+< M4U_PORT_VENC_NBM_WDMA>;
mediatek,vpu = <>;
- clocks = < CLK_TOP_VENCPLL_D2>,
-< CLK_TOP_VENC_SEL>,
-< CLK_TOP_UNIVPLL1_D2>,
-< CLK_TOP_VENC_LT_SEL>;
- clock-names = "venc_sel_src",
- "venc_sel",
- "venc_lt_sel_src",
- "venc_lt_sel";
- assigned-clocks = < CLK_TOP_VENC_SEL>,
- < CLK_TOP_VENC_LT_SEL>;
- assigned-clock-parents = < CLK_TOP_VCODECPLL>,
-<
CLK_TOP_VCODECPLL_370P5>;
+ clocks = < CLK_TOP_VENC_SEL>;
+ clock-names = "venc_sel";
+ assigned-clocks = < CLK_TOP_VENC_SEL>;
+ assigned-clock-parents = < CLK_TOP_VCODECPLL>;
};
jpegdec: jpegdec@18004000 {
@@ -1530,5 +1510,27 @@
< CLK_VENCLT_CKE0>;
clock-names = "apb", "smi";
};
+
+ vcodec_enc_vp8: vcodec@19002000 {
+ compatible = "mediatek,mt8173-vcodec-enc-vp8";
+ reg = <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
+ interrupts = ;
+ iommus = < M4U_PORT_VENC_RCPU_SET2>,
+< M4U_PORT_VENC_REC_FRM_SET2>,
+< M4U_PORT_VENC_BSDMA_SET2>,
+< M4U_PORT_VENC_SV_COMA_SET2>,
+< M4U_PORT_VENC_RD_COMA_SET2>,
+< M4U_PORT_VENC_CUR_LUMA_SET2>,
+< M4U_PORT_VENC_CUR_CHROMA_SET2>,
+< M4U_PORT_VENC_REF_LUMA_SET2>,
+< M4U_PORT_VENC_REC_CHROMA_SET2>;
+ mediatek,larb = <>;
+ mediatek,vpu = <>;
+ clocks = < CLK_TOP_VENC_LT_SEL>;
+ clock-names = "venc_lt_sel";
+ assigned-clocks = < CLK_TOP_VENC_LT_SEL>;
+ assigned-clock-parents =
+< CLK_TOP_VCODECPLL_370P5>;
+ };
};
};
--
2.18.0
[v3,PATCH 1/3] dt-bindings: media: mtk-vcodec: Separating mtk vcodec encoder node
Updates binding document since the avc and vp8 hardware encoder in
MT8173 are now separated. Separate "mediatek,mt8173-vcodec-enc" to
"mediatek,mt8173-vcodec-enc-vp8" and "mediatek,mt8173-vcodec-enc".
This patch separates the two devices, it's a preparing patch for adding
device_link between the larbs and venc-device. It's mainly for fixing
the problem:
https://lkml.org/lkml/2019/9/3/316
Acked-by: Tiffany Lin
Signed-off-by: Hsin-Yi Wang
Signed-off-by: Maoguang Meng
Signed-off-by: Irui Wang
---
Change since v2:
- update dt-bindings commit message
---
.../bindings/media/mediatek-vcodec.txt| 55 ++-
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8217424fd4bd..8318f0ed492d 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -4,7 +4,9 @@ Mediatek Video Codec is the video codec hw present in Mediatek
SoCs which
supports high resolution encoding and decoding functionalities.
Required properties:
-- compatible : "mediatek,mt8173-vcodec-enc" for MT8173 encoder
+- compatible : must be one of the following string:
+ "mediatek,mt8173-vcodec-enc-vp8" for mt8173 vp8 encoder.
+ "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder.
"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
- reg : Physical base address of the video codec registers and length of
@@ -13,10 +15,10 @@ Required properties:
- mediatek,larb : must contain the local arbiters in the current Socs.
- clocks : list of clock specifiers, corresponding to entries in
the clock-names property.
-- clock-names: encoder must contain "venc_sel_src", "venc_sel",,
- "venc_lt_sel_src", "venc_lt_sel", decoder must contain "vcodecpll",
- "univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
- "venc_lt_sel", "vdec_bus_clk_src".
+- clock-names: avc encoder must contain "venc_sel", vp8 encoder must
+ contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2",
+ "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel",
+ "vdec_bus_clk_src".
- iommus : should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
@@ -80,14 +82,10 @@ vcodec_dec: vcodec@1600 {
assigned-clock-rates = <0>, <0>, <0>, <148200>, <8>;
};
- vcodec_enc: vcodec@18002000 {
+vcodec_enc_avc: vcodec@18002000 {
compatible = "mediatek,mt8173-vcodec-enc";
-reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
- <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
-interrupts = ,
-;
-mediatek,larb = <>,
- <>;
+reg = <0 0x18002000 0 0x1000>;
+interrupts = ;
iommus = < M4U_PORT_VENC_RCPU>,
< M4U_PORT_VENC_REC>,
< M4U_PORT_VENC_BSDMA>,
@@ -98,8 +96,20 @@ vcodec_dec: vcodec@1600 {
< M4U_PORT_VENC_REF_LUMA>,
< M4U_PORT_VENC_REF_CHROMA>,
< M4U_PORT_VENC_NBM_RDMA>,
- < M4U_PORT_VENC_NBM_WDMA>,
- < M4U_PORT_VENC_RCPU_SET2>,
+ < M4U_PORT_VENC_NBM_WDMA>;
+mediatek,larb = <>;
+mediatek,vpu = <>;
+clocks = < CLK_TOP_VENC_SEL>;
+clock-names = "venc_sel";
+assigned-clocks = < CLK_TOP_VENC_SEL>;
+assigned-clock-parents = < CLK_TOP_VCODECPLL>;
+ };
+
+vcodec_enc_vp8: vcodec@19002000 {
+compatible = "mediatek,mt8173-vcodec-enc-vp8";
+reg = <0 0x19002000 0 0x1000>;/* VENC_LT_SYS */
+interrupts = ;
+iommus = < M4U_PORT_VENC_RCPU_SET2>,
< M4U_PORT_VENC_REC_FRM_SET2>,
< M4U_PORT_VENC_BSDMA_SET2>,
< M4U_PORT_VENC_SV_COMA_SET2>,
@@ -108,17 +118,10 @@ vcodec_dec: vcodec@1600 {
< M4U_PORT_VENC_CUR_CHROMA_SET2>,
< M4U_PORT_VENC_REF_LUMA_SET2>,
< M4U_PORT_VENC_REC_CHROMA_SET2>;
+mediatek,larb = <>;
mediatek,vpu = <>;
-clocks = < CLK_TOP_VENCPLL_D2>,
- < CLK_TOP_VENC_SEL>,
- < CLK_TOP_UNIVPLL1_D2>,
- < CLK_TOP_VENC_LT_SEL>;
-clock-names = "venc_sel_src",
- "venc_sel",
- "venc_lt_sel_src",
- "venc_lt_sel";
-assigned-clocks = < CLK_TOP_VENC_SEL>,
- < CLK_TOP_VENC_LT_SEL>;
-assigned-clock-parents = < CLK_TOP_VENCPLL_D2>,
- < CLK_TOP_UNIVPLL1_D2>;
+clocks = < CLK_TOP_VENC_LT_SEL>;
+clock-names = "venc_lt_sel";
+assigned-clocks = < CLK_TOP_VENC_LT_SEL>;
+assigned-clock-parents = < CLK_TOP_VCODECPLL_370P5>;
};
--
2.18.0
Re: [PATCH 2/5] mm/page_alloc: Add a bulk page allocator
On Thu, Mar 11, 2021 at 08:42:16AM -0800, Alexander Duyck wrote:
> > @@ -4919,6 +4934,9 @@ static inline bool prepare_alloc_pages(gfp_t
> > gfp_mask, unsigned int order,
> > struct alloc_context *ac, gfp_t *alloc_mask,
> > unsigned int *alloc_flags)
> > {
> > + gfp_mask &= gfp_allowed_mask;
> > + *alloc_mask = gfp_mask;
> > +
> > ac->highest_zoneidx = gfp_zone(gfp_mask);
> > ac->zonelist = node_zonelist(preferred_nid, gfp_mask);
> > ac->nodemask = nodemask;
>
> It might be better to pull this and the change from the bottom out
> into a seperate patch. I was reviewing this and when I hit the bottom
> I apparently had the same question other reviewers had wondering if it
> was intentional. By splitting it out it would be easier to review.
>
Done. I felt it was obvious from context that the paths were sharing code
and splitting it out felt like patch count stuffing. Still, you're the
second person to point it out so now it's a separate patch in v4.
> > @@ -4960,6 +4978,104 @@ static inline bool prepare_alloc_pages(gfp_t
> > gfp_mask, unsigned int order,
> > return true;
> > }
> >
> > +/*
> > + * This is a batched version of the page allocator that attempts to
> > + * allocate nr_pages quickly from the preferred zone and add them to list.
> > + *
> > + * Returns the number of pages allocated.
> > + */
> > +int __alloc_pages_bulk_nodemask(gfp_t gfp_mask, int preferred_nid,
> > + nodemask_t *nodemask, int nr_pages,
> > + struct list_head *alloc_list)
> > +{
> > + struct page *page;
> > + unsigned long flags;
> > + struct zone *zone;
> > + struct zoneref *z;
> > + struct per_cpu_pages *pcp;
> > + struct list_head *pcp_list;
> > + struct alloc_context ac;
> > + gfp_t alloc_mask;
> > + unsigned int alloc_flags;
> > + int alloced = 0;
> > +
> > + if (nr_pages == 1)
> > + goto failed;
>
> I might change this to "<= 1" just to cover the case where somebody
> messed something up and passed a negative value.
>
I put in a WARN_ON_ONCE check that returns 0 allocated pages. It should
be the case that it only happens during the development of a new user but
better safe than sorry. It's an open question whether the max nr_pages
should be clamped but stupidly large values will either fail the watermark
check or wrap and hit the <= 0 check. I guess it's still possible the zone
would hit a dangerously low level of free pages but that is no different
to a user calling __alloc_pages_nodemask a stupidly large number of times.
> > +
> > + /* May set ALLOC_NOFRAGMENT, fragmentation will return 1 page. */
> > + if (!prepare_alloc_pages(gfp_mask, 0, preferred_nid, nodemask, ,
> > _mask, _flags))
> > + return 0;
> > + gfp_mask = alloc_mask;
> > +
> > + /* Find an allowed local zone that meets the high watermark. */
> > + for_each_zone_zonelist_nodemask(zone, z, ac.zonelist,
> > ac.highest_zoneidx, ac.nodemask) {
> > + unsigned long mark;
> > +
> > + if (cpusets_enabled() && (alloc_flags & ALLOC_CPUSET) &&
> > + !__cpuset_zone_allowed(zone, gfp_mask)) {
> > + continue;
> > + }
> > +
> > + if (nr_online_nodes > 1 && zone !=
> > ac.preferred_zoneref->zone &&
> > + zone_to_nid(zone) !=
> > zone_to_nid(ac.preferred_zoneref->zone)) {
> > + goto failed;
> > + }
> > +
> > + mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK) +
> > nr_pages;
> > + if (zone_watermark_fast(zone, 0, mark,
> > + zonelist_zone_idx(ac.preferred_zoneref),
> > + alloc_flags, gfp_mask)) {
> > + break;
> > + }
> > + }
> > + if (!zone)
> > + return 0;
> > +
> > + /* Attempt the batch allocation */
> > + local_irq_save(flags);
> > + pcp = _cpu_ptr(zone->pageset)->pcp;
> > + pcp_list = >lists[ac.migratetype];
> > +
> > + while (alloced < nr_pages) {
> > + page = __rmqueue_pcplist(zone, ac.migratetype, alloc_flags,
> > + pcp,
> > pcp_list);
> > + if (!page)
> > + break;
> > +
> > + list_add(>lru, alloc_list);
> > + alloced++;
> > + }
> > +
> > + if (!alloced)
> > + goto failed_irq;
>
> Since we already covered the case above verifying the nr_pages is
> greater than one it might make sense to move this check inside the
> loop for the !page case. Then we only are checking this if we failed
> an allocation.
>
Yes, good idea, it moves a branch into a very unlikely path.
> > +
> > + if (alloced) {
>
> Isn't this
[PATCH 3/3] powerpc/mm/hash: Avoid multiple HPT resize-downs on memory hotunplug
During memory hotunplug, after each LMB is removed, the HPT may be
resized-down if it would map a max of 4 times the current amount of memory.
(2 shifts, due to introduced histeresis)
It usually is not an issue, but it can take a lot of time if HPT
resizing-down fails. This happens because resize-down failures
usually repeat at each LMB removal, until there are no more bolted entries
conflict, which can take a while to happen.
This can be solved by doing a single HPT resize at the end of memory
hotunplug, after all requested entries are removed.
To make this happen, it's necessary to temporarily disable all HPT
resize-downs before hotunplug, re-enable them after hotunplug ends,
and then resize-down HPT to the current memory size.
As an example, hotunplugging 256GB from a 385GB guest took 621s without
this patch, and 100s after applied.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/book3s/64/hash.h | 2 ++
arch/powerpc/include/asm/sparsemem.h | 2 ++
arch/powerpc/mm/book3s64/hash_utils.c | 28 +++
arch/powerpc/mm/book3s64/pgtable.c| 12
.../platforms/pseries/hotplug-memory.c| 16 +++
5 files changed, 60 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h
b/arch/powerpc/include/asm/book3s/64/hash.h
index 843b0a178590..f92697c107f7 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -256,6 +256,8 @@ int hash__create_section_mapping(unsigned long start,
unsigned long end,
int hash__remove_section_mapping(unsigned long start, unsigned long end);
void hash_memory_batch_expand_prepare(unsigned long newsize);
+void hash_memory_batch_shrink_begin(void);
+void hash_memory_batch_shrink_end(void);
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/include/asm/sparsemem.h
b/arch/powerpc/include/asm/sparsemem.h
index 16b5f5300c84..a7a8a0d070fc 100644
--- a/arch/powerpc/include/asm/sparsemem.h
+++ b/arch/powerpc/include/asm/sparsemem.h
@@ -18,6 +18,8 @@ extern int memory_add_physaddr_to_nid(u64 start);
#define memory_add_physaddr_to_nid memory_add_physaddr_to_nid
void memory_batch_expand_prepare(unsigned long newsize);
+void memory_batch_shrink_begin(void);
+void memory_batch_shrink_end(void);
#ifdef CONFIG_NUMA
extern int hot_add_scn_to_nid(unsigned long scn_addr);
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c
b/arch/powerpc/mm/book3s64/hash_utils.c
index 1f6aa0bf27e7..e16f207de8e4 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -794,6 +794,9 @@ static unsigned long __init htab_get_table_size(void)
}
#ifdef CONFIG_MEMORY_HOTPLUG
+
+atomic_t hpt_resize_disable = ATOMIC_INIT(0);
+
static int resize_hpt_for_hotplug(unsigned long new_mem_size, bool shrinking)
{
unsigned target_hpt_shift;
@@ -805,6 +808,10 @@ static int resize_hpt_for_hotplug(unsigned long
new_mem_size, bool shrinking)
if (shrinking) {
+ /* When batch removing entries, only resizes HPT at the end. */
+ if (atomic_read_acquire(_resize_disable))
+ return 0;
+
/*
* To avoid lots of HPT resizes if memory size is fluctuating
* across a boundary, we deliberately have some hysterisis
@@ -872,6 +879,27 @@ void hash_memory_batch_expand_prepare(unsigned long
newsize)
pr_warn("Hash collision while resizing HPT\n");
}
}
+
+void hash_memory_batch_shrink_begin(void)
+{
+ /* Disable HPT resize-down during hot-unplug */
+ atomic_set_release(_resize_disable, 1);
+}
+
+void hash_memory_batch_shrink_end(void)
+{
+ unsigned long newsize;
+
+ /* Re-enables HPT resize-down after hot-unplug */
+ atomic_set_release(_resize_disable, 0);
+
+ newsize = memblock_phys_mem_size();
+ /* Resize to smallest SHIFT possible */
+ while (resize_hpt_for_hotplug(newsize, true) == -ENOSPC) {
+ newsize *= 2;
+ pr_warn("Hash collision while resizing HPT\n");
+ }
+}
#endif /* CONFIG_MEMORY_HOTPLUG */
static void __init hash_init_partition_table(phys_addr_t hash_table,
diff --git a/arch/powerpc/mm/book3s64/pgtable.c
b/arch/powerpc/mm/book3s64/pgtable.c
index f1cd8af0f67f..e01681e22e00 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -199,6 +199,18 @@ void memory_batch_expand_prepare(unsigned long newsize)
if (!radix_enabled())
hash_memory_batch_expand_prepare(newsize);
}
+
+void memory_batch_shrink_begin(void)
+{
+ if (!radix_enabled())
+ hash_memory_batch_shrink_begin();
+}
+
+void memory_batch_shrink_end(void)
+{
+ if (!radix_enabled())
+ hash_memory_batch_shrink_end();
+}
#endif /* CONFIG_MEMORY_HOTPLUG */
void __init mmu_partition_table_init(void)
diff --git
[PATCH 2/3] powerpc/mm/hash: Avoid multiple HPT resize-ups on memory hotplug
Every time a memory hotplug happens, and the memory limit crosses a 2^n
value, it may be necessary to perform HPT resizing-up, which can take
some time (over 100ms in my tests).
It usually is not an issue, but it can take some time if a lot of memory
is added to a guest with little starting memory:
Adding 256G to a 2GB guest, for example will require 8 HPT resizes.
Perform an HPT resize before memory hotplug, updating HPT to its
final size (considering a successful hotplug), taking the number of
HPT resizes to at most one per memory hotplug action.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/book3s/64/hash.h | 2 ++
arch/powerpc/include/asm/sparsemem.h| 2 ++
arch/powerpc/mm/book3s64/hash_utils.c | 14 ++
arch/powerpc/mm/book3s64/pgtable.c | 6 ++
arch/powerpc/platforms/pseries/hotplug-memory.c | 6 ++
5 files changed, 30 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h
b/arch/powerpc/include/asm/book3s/64/hash.h
index d959b0195ad9..843b0a178590 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -255,6 +255,8 @@ int hash__create_section_mapping(unsigned long start,
unsigned long end,
int nid, pgprot_t prot);
int hash__remove_section_mapping(unsigned long start, unsigned long end);
+void hash_memory_batch_expand_prepare(unsigned long newsize);
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_BOOK3S_64_HASH_H */
diff --git a/arch/powerpc/include/asm/sparsemem.h
b/arch/powerpc/include/asm/sparsemem.h
index d072866842e4..16b5f5300c84 100644
--- a/arch/powerpc/include/asm/sparsemem.h
+++ b/arch/powerpc/include/asm/sparsemem.h
@@ -17,6 +17,8 @@ extern int remove_section_mapping(unsigned long start,
unsigned long end);
extern int memory_add_physaddr_to_nid(u64 start);
#define memory_add_physaddr_to_nid memory_add_physaddr_to_nid
+void memory_batch_expand_prepare(unsigned long newsize);
+
#ifdef CONFIG_NUMA
extern int hot_add_scn_to_nid(unsigned long scn_addr);
#else
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c
b/arch/powerpc/mm/book3s64/hash_utils.c
index cfb3ec164f56..1f6aa0bf27e7 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -858,6 +858,20 @@ int hash__remove_section_mapping(unsigned long start,
unsigned long end)
return rc;
}
+
+void hash_memory_batch_expand_prepare(unsigned long newsize)
+{
+ /*
+* Resizing-up HPT should never fail, but there are some cases system
starts with higher
+* SHIFT than required, and we go through the funny case of resizing
HPT down while
+* adding memory
+*/
+
+ while (resize_hpt_for_hotplug(newsize, false) == -ENOSPC) {
+ newsize *= 2;
+ pr_warn("Hash collision while resizing HPT\n");
+ }
+}
#endif /* CONFIG_MEMORY_HOTPLUG */
static void __init hash_init_partition_table(phys_addr_t hash_table,
diff --git a/arch/powerpc/mm/book3s64/pgtable.c
b/arch/powerpc/mm/book3s64/pgtable.c
index 5b3a3bae21aa..f1cd8af0f67f 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -193,6 +193,12 @@ int __meminit remove_section_mapping(unsigned long start,
unsigned long end)
return hash__remove_section_mapping(start, end);
}
+
+void memory_batch_expand_prepare(unsigned long newsize)
+{
+ if (!radix_enabled())
+ hash_memory_batch_expand_prepare(newsize);
+}
#endif /* CONFIG_MEMORY_HOTPLUG */
void __init mmu_partition_table_init(void)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 8377f1f7c78e..353c71249214 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -671,6 +671,8 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
if (lmbs_available < lmbs_to_add)
return -EINVAL;
+ memory_batch_expand_prepare(memblock_phys_mem_size() + lmbs_to_add *
drmem_lmb_size());
+
for_each_drmem_lmb(lmb) {
if (lmb->flags & DRCONF_MEM_ASSIGNED)
continue;
@@ -734,6 +736,8 @@ static int dlpar_memory_add_by_index(u32 drc_index)
pr_info("Attempting to hot-add LMB, drc index %x\n", drc_index);
+ memory_batch_expand_prepare(memblock_phys_mem_size() +
+drmem_info->n_lmbs * drmem_lmb_size());
lmb_found = 0;
for_each_drmem_lmb(lmb) {
if (lmb->drc_index == drc_index) {
@@ -788,6 +792,8 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32
drc_index)
if (lmbs_available < lmbs_to_add)
return -EINVAL;
+ memory_batch_expand_prepare(memblock_phys_mem_size() + lmbs_to_add *
drmem_lmb_size());
+
for_each_drmem_lmb_in_range(lmb,
[PATCH 0/3] powerpc/mm/hash: Time improvements for memory hot(un)plug
This patchset intends to reduce time needed for processing memory hotplug/hotunplug in hash guests. The first one, makes sure guests with pagesize over 4k don't need to go through HPT resize-downs after memory hotplug. The second and third patches make hotplug / hotunplug perform a single HPT resize per operation, instead of one for each shift change, or one for each LMB in case of resize-down error. Why haven't the same mechanism used for both memory hotplug and hotunplug? They both have different requirements: Memory hotplug causes (usually) HPT resize-ups, which are fine happening at the start of hotplug, but resize-ups should not ever be disabled, as other mechanisms may try to increase memory, hitting issues with a HPT that is too small. Memory hotunplug causes HPT resize-downs, which can be disabled (HPT will just remain larger for a while), but need to happen at the end of an hotunplug operation. If we want to batch it, we need to disable resize-downs and perform it only at the end. Tests done with this patchset in the same machine / guest config: Starting memory: 129GB, DIMM: 256GB Before patchset: hotplug = 710s, hotunplug = 621s. After patchset: hotplug = 21s, hotunplug = 100s. Any feedback will be appreciated! I believe the code may not be very well placed in available files, so please give some feedback on that. Best regards, Leonardo Bras (3): powerpc/mm/hash: Avoid resizing-down HPT on first memory hotplug powerpc/mm/hash: Avoid multiple HPT resize-ups on memory hotplug powerpc/mm/hash: Avoid multiple HPT resize-downs on memory hotunplug arch/powerpc/include/asm/book3s/64/hash.h | 4 + arch/powerpc/include/asm/sparsemem.h | 4 + arch/powerpc/mm/book3s64/hash_utils.c | 78 +++ arch/powerpc/mm/book3s64/pgtable.c| 18 + .../platforms/pseries/hotplug-memory.c| 22 ++ 5 files changed, 111 insertions(+), 15 deletions(-) -- 2.29.2
[PATCH 1/3] powerpc/mm/hash: Avoid resizing-down HPT on first memory hotplug
Because hypervisors may need to create HPTs without knowing the guest
page size, the smallest used page-size (4k) may be chosen, resulting in
a HPT that is possibly bigger than needed.
On a guest with bigger page-sizes, the amount of entries for HTP may be
too high, causing the guest to ask for a HPT resize-down on the first
hotplug.
This becomes a problem when HPT resize-down fails, and causes the
HPT resize to be performed on every LMB added, until HPT size is
compatible to guest memory size, causing a major slowdown.
So, avoiding HPT resizing-down on hot-add significantly improves memory
hotplug times.
As an example, hotplugging 256GB on a 129GB guest took 710s without this
patch, and 21s after applied.
Signed-off-by: Leonardo Bras
---
arch/powerpc/mm/book3s64/hash_utils.c | 36 ---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c
b/arch/powerpc/mm/book3s64/hash_utils.c
index 73b06adb6eeb..cfb3ec164f56 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -794,7 +794,7 @@ static unsigned long __init htab_get_table_size(void)
}
#ifdef CONFIG_MEMORY_HOTPLUG
-static int resize_hpt_for_hotplug(unsigned long new_mem_size)
+static int resize_hpt_for_hotplug(unsigned long new_mem_size, bool shrinking)
{
unsigned target_hpt_shift;
@@ -803,19 +803,25 @@ static int resize_hpt_for_hotplug(unsigned long
new_mem_size)
target_hpt_shift = htab_shift_for_mem_size(new_mem_size);
- /*
-* To avoid lots of HPT resizes if memory size is fluctuating
-* across a boundary, we deliberately have some hysterisis
-* here: we immediately increase the HPT size if the target
-* shift exceeds the current shift, but we won't attempt to
-* reduce unless the target shift is at least 2 below the
-* current shift
-*/
- if (target_hpt_shift > ppc64_pft_size ||
- target_hpt_shift < ppc64_pft_size - 1)
- return mmu_hash_ops.resize_hpt(target_hpt_shift);
+ if (shrinking) {
- return 0;
+ /*
+* To avoid lots of HPT resizes if memory size is fluctuating
+* across a boundary, we deliberately have some hysterisis
+* here: we immediately increase the HPT size if the target
+* shift exceeds the current shift, but we won't attempt to
+* reduce unless the target shift is at least 2 below the
+* current shift
+*/
+
+ if (target_hpt_shift >= ppc64_pft_size - 1)
+ return 0;
+
+ } else if (target_hpt_shift <= ppc64_pft_size) {
+ return 0;
+ }
+
+ return mmu_hash_ops.resize_hpt(target_hpt_shift);
}
int hash__create_section_mapping(unsigned long start, unsigned long end,
@@ -828,7 +834,7 @@ int hash__create_section_mapping(unsigned long start,
unsigned long end,
return -1;
}
- resize_hpt_for_hotplug(memblock_phys_mem_size());
+ resize_hpt_for_hotplug(memblock_phys_mem_size(), false);
rc = htab_bolt_mapping(start, end, __pa(start),
pgprot_val(prot), mmu_linear_psize,
@@ -847,7 +853,7 @@ int hash__remove_section_mapping(unsigned long start,
unsigned long end)
int rc = htab_remove_mapping(start, end, mmu_linear_psize,
mmu_kernel_ssize);
- if (resize_hpt_for_hotplug(memblock_phys_mem_size()) == -ENOSPC)
+ if (resize_hpt_for_hotplug(memblock_phys_mem_size(), true) == -ENOSPC)
pr_warn("Hash collision while resizing HPT\n");
return rc;
--
2.29.2
[PATCH] pinctrl: core: Set ret to 0 when group is skipped
Static analyzer tool found that the ret variable is not initialized but
code expects ret value >=0 when pinconf is skipped in the first pinmux
loop. The same expectation is for pinmux in a pinconf loop.
That's why initialize ret to 0 to avoid uninitialized ret value in first
loop or reusing ret value from first loop in second.
Addresses-Coverity: ("Uninitialized variables")
Signed-off-by: Michal Simek
CC: Colin Ian King
CC: Dan Carpenter
---
drivers/pinctrl/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index f5c32d2a3c91..136c323d855e 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1266,6 +1266,7 @@ static int pinctrl_commit_state(struct pinctrl *p, struct
pinctrl_state *state)
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
case PIN_MAP_TYPE_CONFIGS_GROUP:
+ ret = 0;
break;
default:
ret = -EINVAL;
@@ -1284,6 +1285,7 @@ static int pinctrl_commit_state(struct pinctrl *p, struct
pinctrl_state *state)
list_for_each_entry(setting, >settings, node) {
switch (setting->type) {
case PIN_MAP_TYPE_MUX_GROUP:
+ ret = 0;
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
case PIN_MAP_TYPE_CONFIGS_GROUP:
--
2.30.1
[PATCH] net: ipv4: route.c: Fix indentation of multi line comment.
All comment lines inside the comment block have been aligned.
Every line of comment starts with a * (uniformity in code).
Signed-off-by: Shubhankar Kuranagatti
---
net/ipv4/route.c | 97
1 file changed, 49 insertions(+), 48 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 02d81d79deeb..b930f5976961 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -722,6 +722,7 @@ static void update_or_create_fnhe(struct fib_nh_common
*nhc, __be32 daddr,
for_each_possible_cpu(i) {
struct rtable __rcu **prt;
+
prt = per_cpu_ptr(nhc->nhc_pcpu_rth_output, i);
rt = rcu_dereference(*prt);
if (rt)
@@ -1258,12 +1259,12 @@ static int ip_rt_bug(struct net *net, struct sock *sk,
struct sk_buff *skb)
}
/*
- We do not cache source address of outgoing interface,
- because it is used only by IP RR, TS and SRR options,
- so that it out of fast path.
-
- BTW remember: "addr" is allowed to be not aligned
- in IP options!
+ * We do not cache source address of outgoing interface,
+ * because it is used only by IP RR, TS and SRR options,
+ * so that it out of fast path.
+ *
+ * BTW remember: "addr" is allowed to be not aligned
+ * in IP options!
*/
void ip_rt_get_source(u8 *addr, struct sk_buff *skb, struct rtable *rt)
@@ -2108,7 +2109,7 @@ static int ip_route_input_slow(struct sk_buff *skb,
__be32 daddr, __be32 saddr,
goto out;
/* Check for the most weird martians, which can be not detected
- by fib_lookup.
+* by fib_lookup.
*/
tun_info = skb_tunnel_info(skb);
@@ -2317,15 +2318,15 @@ int ip_route_input_rcu(struct sk_buff *skb, __be32
daddr, __be32 saddr,
u8 tos, struct net_device *dev, struct fib_result *res)
{
/* Multicast recognition logic is moved from route cache to here.
- The problem was that too many Ethernet cards have broken/missing
- hardware multicast filters :-( As result the host on multicasting
- network acquires a lot of useless route cache entries, sort of
- SDR messages from all the world. Now we try to get rid of them.
- Really, provided software IP multicast filter is organized
- reasonably (at least, hashed), it does not result in a slowdown
- comparing with route cache reject entries.
- Note, that multicast routers are not affected, because
- route cache entry is created eventually.
+* The problem was that too many Ethernet cards have broken/missing
+* hardware multicast filters :-( As result the host on multicasting
+* network acquires a lot of useless route cache entries, sort of
+* SDR messages from all the world. Now we try to get rid of them.
+* Really, provided software IP multicast filter is organized
+* reasonably (at least, hashed), it does not result in a slowdown
+* comparing with route cache reject entries.
+* Note, that multicast routers are not affected, because
+* route cache entry is created eventually.
*/
if (ipv4_is_multicast(daddr)) {
struct in_device *in_dev = __in_dev_get_rcu(dev);
@@ -2537,11 +2538,11 @@ struct rtable *ip_route_output_key_hash_rcu(struct net
*net, struct flowi4 *fl4,
rth = ERR_PTR(-ENETUNREACH);
/* I removed check for oif == dev_out->oif here.
- It was wrong for two reasons:
- 1. ip_dev_find(net, saddr) can return wrong iface, if saddr
- is assigned to multiple interfaces.
- 2. Moreover, we are allowed to send packets with saddr
- of another iface. --ANK
+* It was wrong for two reasons:
+* 1. ip_dev_find(net, saddr) can return wrong iface, if saddr
+*is assigned to multiple interfaces.
+* 2. Moreover, we are allowed to send packets with saddr
+*of another iface. --ANK
*/
if (fl4->flowi4_oif == 0 &&
@@ -2553,18 +2554,18 @@ struct rtable *ip_route_output_key_hash_rcu(struct net
*net, struct flowi4 *fl4,
goto out;
/* Special hack: user can direct multicasts
- and limited broadcast via necessary interface
- without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
- This hack is not just for fun, it allows
- vic,vat and friends to work.
- They bind socket to loopback, set ttl to zero
- and expect that it will work.
- From the viewpoint of routing cache they are broken,
- because we are not allowed to build
Re: [PATCH] dt-bindings: media: Convert video-mux to DT schema
Hi Laurent,
On Fri, Mar 12, 2021 at 03:25:11AM +0200, Laurent Pinchart wrote:
> Hi Rob,
>
> Thank you for the patch.
>
> On Thu, Mar 11, 2021 at 04:40:42PM -0700, Rob Herring wrote:
> > Now that we have the graph schema, convert the video-mux binding to DT
> > schema.
> >
> > Cc: Sakari Ailus
> > Cc: Laurent Pinchart
> > Cc: Mauro Carvalho Chehab
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Rob Herring
> > ---
> > .../devicetree/bindings/media/video-mux.txt | 60
> > .../devicetree/bindings/media/video-mux.yaml | 93 +++
> > 2 files changed, 93 insertions(+), 60 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/media/video-mux.txt
> > create mode 100644 Documentation/devicetree/bindings/media/video-mux.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/media/video-mux.txt
> > b/Documentation/devicetree/bindings/media/video-mux.txt
> > deleted file mode 100644
> > index 63b9dc913e45..
> > --- a/Documentation/devicetree/bindings/media/video-mux.txt
> > +++ /dev/null
> > @@ -1,60 +0,0 @@
> > -Video Multiplexer
> > -=
> > -
> > -Video multiplexers allow to select between multiple input ports. Video
> > received
> > -on the active input port is passed through to the output port. Muxes
> > described
> > -by this binding are controlled by a multiplexer controller that is
> > described by
> > -the bindings in Documentation/devicetree/bindings/mux/mux-controller.txt
> > -
> > -Required properties:
> > -- compatible : should be "video-mux"
> > -- mux-controls : mux controller node to use for operating the mux
> > -- #address-cells: should be <1>
> > -- #size-cells: should be <0>
> > -- port@*: at least three port nodes containing endpoints connecting to the
> > - source and sink devices according to of_graph bindings. The last port is
> > - the output port, all others are inputs.
> > -
> > -Optionally, #address-cells, #size-cells, and port nodes can be grouped
> > under a
> > -ports node as described in Documentation/devicetree/bindings/graph.txt.
> > -
> > -Example:
> > -
> > - mux: mux-controller {
> > - compatible = "gpio-mux";
> > - #mux-control-cells = <0>;
> > -
> > - mux-gpios = < 15 GPIO_ACTIVE_HIGH>;
> > - };
> > -
> > - video-mux {
> > - compatible = "video-mux";
> > - mux-controls = <>;
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - port@0 {
> > - reg = <0>;
> > -
> > - mux_in0: endpoint {
> > - remote-endpoint = <_source0_out>;
> > - };
> > - };
> > -
> > - port@1 {
> > - reg = <1>;
> > -
> > - mux_in1: endpoint {
> > - remote-endpoint = <_source1_out>;
> > - };
> > - };
> > -
> > - port@2 {
> > - reg = <2>;
> > -
> > - mux_out: endpoint {
> > - remote-endpoint = <_interface_in>;
> > - };
> > - };
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/media/video-mux.yaml
> > b/Documentation/devicetree/bindings/media/video-mux.yaml
> > new file mode 100644
> > index ..780fbbd46a38
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/video-mux.yaml
> > @@ -0,0 +1,93 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/video-mux.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Video Multiplexer
> > +
> > +maintainers:
> > + - Sakari Ailus
> > + - Laurent Pinchart
> > +
> > +description:
> > + Video multiplexers allow to select between multiple input ports. Video
> > + received on the active input port is passed through to the output port.
> > Muxes
> > + described by this binding are controlled by a multiplexer controller.
> > +
> > +properties:
> > + compatible:
> > +const: video-mux
> > +
> > + mux-controls:
> > +maxItems: 1
> > +
> > + '#address-cells':
> > +const: 1
> > +
> > + '#size-cells':
> > +const: 0
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +patternProperties:
> > + '^port@':
> > +$ref: /schemas/graph.yaml#/properties/port
>
> Should we require at least port@0, port@1 and port@2 ?
>
> > +
> > +patternProperties:
> > + '^port@':
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description:
> > + At least three port nodes containing endpoints connecting to the
> > source
> > + and sink devices according to of_graph bindings. The last port is the
> > + output port, all others are inputs.
> > +
> > +required:
> > + - compatible
> > + - mux-controls
>
> Should a constraint be added to ensure that either a ports node or
> port@0, port@1 and
Re: [PATCH] dt-bindings: i3c: Fix silvaco,i3c-master-v1 compatible string
Rob Herring wrote on Thu, 11 Mar 2021 16:40:56 -0700:
> The example for the Silvaco I3C master doesn't match the schema's
> compatible string. Fix it.
>
> Cc: Miquel Raynal
> Cc: Conor Culhane
> Cc: Alexandre Belloni
> Cc: linux-...@lists.infradead.org
> Signed-off-by: Rob Herring
> ---
> Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
> b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
> index adb5165505aa..62f3ca66274f 100644
> --- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
> +++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
> @@ -49,7 +49,7 @@ additionalProperties: true
> examples:
>- |
> i3c-master@a000 {
> -compatible = "silvaco,i3c-master";
> +compatible = "silvaco,i3c-master-v1";
> clocks = <_clk 71>, <>, <>;
> clock-names = "pclk", "fast_clk", "slow_clk";
> interrupt-parent = <>;
Reviewed-by: Miquel Raynal
Re: [PATCH] net: ethernet: dec: tulip: Random spelling fixes throughout the file pnic2.c
On 3/11/21 11:05 PM, Bhaskar Chowdhury wrote: > > Random spelling fixes throughout the file. > > Signed-off-by: Bhaskar Chowdhury > --- > drivers/net/ethernet/dec/tulip/pnic2.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/dec/tulip/pnic2.c > b/drivers/net/ethernet/dec/tulip/pnic2.c > index 412adaa7fdf8..04daffb8db2a 100644 > --- a/drivers/net/ethernet/dec/tulip/pnic2.c > +++ b/drivers/net/ethernet/dec/tulip/pnic2.c > @@ -107,7 +107,7 @@ void pnic2_start_nway(struct net_device *dev) > */ > csr14 = (ioread32(ioaddr + CSR14) & 0xfff0ee39); > > -/* bit 17 - advetise 100baseTx-FD */ > +/* bit 17 - advertise 100baseTx-FD */ OK above. But: https://en.wikipedia.org/wiki/Autonegotiation > if (tp->sym_advertise & 0x0100) csr14 |= 0x0002; > > /* bit 16 - advertise 100baseTx-HD */ > @@ -116,7 +116,7 @@ void pnic2_start_nway(struct net_device *dev) > /* bit 6 - advertise 10baseT-HD */ > if (tp->sym_advertise & 0x0020) csr14 |= 0x0040; > > -/* Now set bit 12 Link Test Enable, Bit 7 Autonegotiation Enable > +/* Now set bit 12 Link Test Enable, Bit 7 Auto negotiation Enable > * and bit 0 Don't PowerDown 10baseT > */ > csr14 |= 0x1184; > @@ -157,7 +157,7 @@ void pnic2_start_nway(struct net_device *dev) > /* all set up so now force the negotiation to begin */ > > /* read in current values and mask off all but the > - * Autonegotiation bits 14:12. Writing a 001 to those bits > + * Auto negotiation bits 14:12. Writing a 001 to those bits > * should start the autonegotiation > */ > csr12 = (ioread32(ioaddr + CSR12) & 0x8fff); > @@ -290,7 +290,7 @@ void pnic2_lnk_change(struct net_device *dev, int csr5) > csr14 = (ioread32(ioaddr + CSR14) & 0xff7f); > iowrite32(csr14,ioaddr + CSR14); > > -/* what should we do when autonegotiate fails? > +/* what should we do when auto negotiate fails? > * should we try again or default to baseline > * case. I just don't know. > * > -- -- ~Randy
[tip:locking/core] BUILD SUCCESS c2e4bfe0eef313eeb1c4c9d921be7a9d91d5d71a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core branch HEAD: c2e4bfe0eef313eeb1c4c9d921be7a9d91d5d71a kernel/futex: Explicitly document pi_lock for pi_state owner fixup elapsed time: 723m configs tested: 135 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arc defconfig arm mxs_defconfig sh secureedge5410_defconfig ia64 tiger_defconfig arm spitz_defconfig ia64 alldefconfig mips rt305x_defconfig arm mv78xx0_defconfig arm exynos_defconfig m68km5272c3_defconfig arm nhk8815_defconfig powerpc mpc836x_rdk_defconfig mipsqi_lb60_defconfig powerpc tqm8555_defconfig openrisc simple_smp_defconfig um x86_64_defconfig powerpcmvme5100_defconfig mipsjmr3927_defconfig shhp6xx_defconfig powerpc lite5200b_defconfig arm u8500_defconfig mips allmodconfig mipsgpr_defconfig arm mainstone_defconfig powerpc eiger_defconfig mips pistachio_defconfig mipsworkpad_defconfig openriscdefconfig arm am200epdkit_defconfig sparc defconfig pariscgeneric-64bit_defconfig mips malta_defconfig m68kmvme147_defconfig powerpc ppc40x_defconfig powerpc tqm8548_defconfig arm s3c6400_defconfig sh allmodconfig mipsnlm_xlr_defconfig powerpcge_imp3a_defconfig arm iop32x_defconfig sparc sparc32_defconfig shedosk7705_defconfig powerpc mpc836x_mds_defconfig armqcom_defconfig riscvalldefconfig powerpc taishan_defconfig armneponset_defconfig powerpc mpc8315_rdb_defconfig arm corgi_defconfig arm eseries_pxa_defconfig mips rs90_defconfig armmini2440_defconfig powerpc tqm8560_defconfig powerpc iss476-smp_defconfig arm aspeed_g4_defconfig powerpc redwood_defconfig mipsmalta_qemu_32r6_defconfig mips ci20_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig i386 tinyconfig i386defconfig mips allyesconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20210312 i386 randconfig-a005-20210312 i386 randconfig-a002-20210312 i386 randconfig-a003-20210312 i386 randconfig-a004-20210312 i386 randconfig-a006-20210312 i386 randconfig-a001-20210311 i386 randconfig-a003-20210311 i386
[PATCH] drm/omap: dsi: fix unsigned expression compared with zero
From: Junlin Yang
r is "u32" always >= 0,mipi_dsi_create_packet may return little than zero.
so r < 0 condition is never accessible.
Fixes coccicheck warnings:
./drivers/gpu/drm/omapdrm/dss/dsi.c:2155:5-6:
WARNING: Unsigned expression compared with zero: r < 0
Signed-off-by: Junlin Yang
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 8e11612..b31d750 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -2149,11 +2149,12 @@ static int dsi_vc_send_short(struct dsi_data *dsi, int
vc,
const struct mipi_dsi_msg *msg)
{
struct mipi_dsi_packet pkt;
+ int ret;
u32 r;
- r = mipi_dsi_create_packet(, msg);
- if (r < 0)
- return r;
+ ret = mipi_dsi_create_packet(, msg);
+ if (ret < 0)
+ return ret;
WARN_ON(!dsi_bus_is_locked(dsi));
--
1.9.1
Re: [PATCH] perf annotate: Fix sample events lost in stdio mode
Hello,
On 2021/3/12 13:49, Namhyung Kim wrote:
Hi,
On Fri, Mar 12, 2021 at 12:24 PM Yang Jihong wrote:
Hello, Namhyung
On 2021/3/11 22:42, Namhyung Kim wrote:
Hi,
On Thu, Mar 11, 2021 at 5:48 PM Yang Jihong wrote:
Hello,
On 2021/3/6 16:28, Yang Jihong wrote:
In hist__find_annotations function, since have a hist_entry per IP for the same
symbol, we free notes->src to signal already processed this symbol in stdio
mode;
when annotate, entry will skipped if notes->src is NULL to avoid repeated
output.
I'm not sure it's still true that we have a hist_entry per IP.
Afaik the default sort key is comm,dso,sym which means it should have a single
hist_entry for each symbol. It seems like an old comment..
Emm, yes, we have a hist_entry for per IP.
a member named "sym" in struct "hist_entry" points to symbol,
different IP may point to the same symbol.
Are you sure about this? It seems like a bug then.
Yes, now each IP corresponds to a hist_entry :)
Last week I found that some sample events were missing when perf
annotate in stdio mode, so I went through the annotate code carefully.
The event handling process is as follows:
process_sample_event
evsel_add_sample
hists__add_entry
__hists__add_entry
hists__findnew_entry
hist_entry__new -> here allock new hist_entry
hist_entry__inc_addr_samples
symbol__inc_addr_samples
symbol__hists
annotated_source__new-> here alloc annotate soruce
annotated_source__alloc_histograms -> here alloc histograms
By bugs, do you mean there's something wrong?
The hist_entry struct is as follows:
struct hist_entry {
...
struct map_symbol ms;
...
};
struct map_symbol {
struct maps *maps;
struct map *map;
struct symbol *sym;
};
However, there is a problem, for example, run the following command:
# perf record -e branch-misses -e branch-instructions -a sleep 1
perf.data file contains different types of sample event.
If the same IP sample event exists in branch-misses and branch-instructions,
this event uses the same symbol. When annotate branch-misses events, notes->src
corresponding to this event is set to null, as a result, when annotate
branch-instructions events, this event is skipped and no annotate is output.
Solution of this patch is to add a u8 member to struct sym_hist and use a bit to
indicate whether the symbol has been processed.
Because different types of event correspond to different sym_hist, no conflict
occurs.
---
tools/perf/builtin-annotate.c | 22 ++
tools/perf/util/annotate.h| 4
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index a23ba6bb99b6..c8c67892ae82 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -372,15 +372,21 @@ static void hists__find_annotations(struct hists *hists,
if (next != NULL)
nd = next;
} else {
- hist_entry__tty_annotate(he, evsel, ann);
+ struct sym_hist *h =
annotated_source__histogram(notes->src,
+
evsel->idx);
+
+ if (h->processed == 0) {
+ hist_entry__tty_annotate(he, evsel, ann);
+
+ /*
+ * Since we have a hist_entry per IP for the same
+ * symbol, set processed flag of evsel in sym_hist
+ * to signal we already processed this symbol.
+ */
+ h->processed = 1;
+ }
+
nd = rb_next(nd);
- /*
- * Since we have a hist_entry per IP for the same
- * symbol, free he->ms.sym->src to signal we already
- * processed this symbol.
- */
- zfree(>src->cycles_hist);
- zfree(>src);
}
}
}
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 096cdaf21b01..89872bfdc958 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -228,6 +228,10 @@ void symbol__calc_percent(struct symbol *sym, struct evsel
*evsel);
struct sym_hist {
u64 nr_samples;
u64 period;
+
+ u8processed : 1, /* whether symbol has been
processed, used for annotate */
+ __reserved : 7;
I think just a bool member is fine.
OK, I have submitted the v2 patch and changed to bool member, new patch
is as follows, look forward to your review:
https://lore.kernel.org/patchwork/patch/1393901/
+
struct sym_hist_entry
RE: Re: [PATCH v26 2/4] scsi: ufs: L2P map management for HPB read
>>> > This is a patch for managing L2P map in HPB module.
>>> >
>>> > The HPB divides logical addresses into several regions. A region
>>> > consists
>>> > of several sub-regions. The sub-region is a basic unit where L2P
>>> > mapping is
>>> > managed. The driver loads L2P mapping data of each sub-region. The
>>> > loaded
>>> > sub-region is called active-state. The HPB driver unloads L2P mapping
>>> > data
>>> > as region unit. The unloaded region is called inactive-state.
>>> >
>>> > Sub-region/region candidates to be loaded and unloaded are delivered
>>> > from
>>> > the UFS device. The UFS device delivers the recommended active
>>> > sub-region
>>> > and inactivate region to the driver using sensedata.
>>> > The HPB module performs L2P mapping management on the host through the
>>> > delivered information.
>>> >
>>> > A pinned region is a pre-set regions on the UFS device that is always
>>> > activate-state.
>>> >
>>> > The data structure for map data request and L2P map uses mempool API,
>>> > minimizing allocation overhead while avoiding static allocation.
>>> >
>>> > The mininum size of the memory pool used in the HPB is implemented
>>> > as a module parameter, so that it can be configurable by the user.
>>> >
>>> > To gurantee a minimum memory pool size of 4MB:
>>> > ufshpb_host_map_kbytes=4096
>>> >
>>> > The map_work manages active/inactive by 2 "to-do" lists.
>>> > Each hpb lun maintains 2 "to-do" lists:
>>> > hpb->lh_inact_rgn - regions to be inactivated, and
>>> > hpb->lh_act_srgn - subregions to be activated
>>> > Those lists are maintained on IO completion.
>>> >
>>> > Reviewed-by: Bart Van Assche
>>> > Reviewed-by: Can Guo
>>> > Acked-by: Avri Altman
>>> > Tested-by: Bean Huo
>>> > Signed-off-by: Daejun Park
>>> > ---
>>> > drivers/scsi/ufs/ufs.h| 36 ++
>>> > drivers/scsi/ufs/ufshcd.c |4 +
>>> > drivers/scsi/ufs/ufshpb.c | 1091 -
>>> > drivers/scsi/ufs/ufshpb.h | 65 +++
>>> > 4 files changed, 1181 insertions(+), 15 deletions(-)
>>> >
>>> > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
>>> > index 65563635e20e..957763db1006 100644
>>> > --- a/drivers/scsi/ufs/ufs.h
>>> > +++ b/drivers/scsi/ufs/ufs.h
>>> > @@ -472,6 +472,41 @@ struct utp_cmd_rsp {
>>> > u8 sense_data[UFS_SENSE_SIZE];
>>> > };
>>> >
>>> > +struct ufshpb_active_field {
>>> > +__be16 active_rgn;
>>> > +__be16 active_srgn;
>>> > +};
>>> > +#define HPB_ACT_FIELD_SIZE 4
>>> > +
>>> > +/**
>>> > + * struct utp_hpb_rsp - Response UPIU structure
>>> > + * @residual_transfer_count: Residual transfer count DW-3
>>> > + * @reserved1: Reserved double words DW-4 to DW-7
>>> > + * @sense_data_len: Sense data length DW-8 U16
>>> > + * @desc_type: Descriptor type of sense data
>>> > + * @additional_len: Additional length of sense data
>>> > + * @hpb_op: HPB operation type
>>> > + * @lun: LUN of response UPIU
>>> > + * @active_rgn_cnt: Active region count
>>> > + * @inactive_rgn_cnt: Inactive region count
>>> > + * @hpb_active_field: Recommended to read HPB region and subregion
>>> > + * @hpb_inactive_field: To be inactivated HPB region and subregion
>>> > + */
>>> > +struct utp_hpb_rsp {
>>> > +__be32 residual_transfer_count;
>>> > +__be32 reserved1[4];
>>> > +__be16 sense_data_len;
>>> > +u8 desc_type;
>>> > +u8 additional_len;
>>> > +u8 hpb_op;
>>> > +u8 lun;
>>> > +u8 active_rgn_cnt;
>>> > +u8 inactive_rgn_cnt;
>>> > +struct ufshpb_active_field hpb_active_field[2];
>>> > +__be16 hpb_inactive_field[2];
>>> > +};
>>> > +#define UTP_HPB_RSP_SIZE 40
>>> > +
>>> > /**
>>> > * struct utp_upiu_rsp - general upiu response structure
>>> > * @header: UPIU header structure DW-0 to DW-2
>>> > @@ -482,6 +517,7 @@ struct utp_upiu_rsp {
>>> > struct utp_upiu_header header;
>>> > union {
>>> > struct utp_cmd_rsp sr;
>>> > +struct utp_hpb_rsp hr;
>>> > struct utp_upiu_query qr;
>>> > };
>>> > };
>>> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>> > index 49b3d5d24fa6..5852ff44c3cc 100644
>>> > --- a/drivers/scsi/ufs/ufshcd.c
>>> > +++ b/drivers/scsi/ufs/ufshcd.c
>>> > @@ -5021,6 +5021,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba,
>>> > struct ufshcd_lrb *lrbp)
>>> > */
>>> > pm_runtime_get_noresume(hba->dev);
>>> > }
>>> > +
>>> > +if (scsi_status == SAM_STAT_GOOD)
>>> > +ufshpb_rsp_upiu(hba, lrbp);
>>> > break;
>>> > case UPIU_TRANSACTION_REJECT_UPIU:
>>> > /* TODO: handle Reject UPIU Response */
>>> > @@ -9221,6 +9224,7 @@ EXPORT_SYMBOL(ufshcd_shutdown);
>>> > void ufshcd_remove(struct ufs_hba *hba)
>>> > {
>>> >
Re: [PATCH v2 6/6] media: uvcvideo: Set a different name for the metadata entity
On 12/03/2021 00:38, Laurent Pinchart wrote: > Hi Ricardo, > > Thank you for the patch. > > On Thu, Mar 11, 2021 at 11:19:46PM +0100, Ricardo Ribalda wrote: >> All the entities must have a unique name. >> >> Fixes v4l2-compliance: >> Media Controller ioctls: >> fail: v4l2-test-media.cpp(205): >> v2_entity_names_set.find(key) != v2_entity_names_set.end() >> test MEDIA_IOC_G_TOPOLOGY: FAIL >> fail: v4l2-test-media.cpp(394): num_data_links != num_links >> test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL >> >> Signed-off-by: Ricardo Ribalda >> --- >> drivers/media/usb/uvc/uvc_driver.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/media/usb/uvc/uvc_driver.c >> b/drivers/media/usb/uvc/uvc_driver.c >> index 30ef2a3110f7..47efa9a9be99 100644 >> --- a/drivers/media/usb/uvc/uvc_driver.c >> +++ b/drivers/media/usb/uvc/uvc_driver.c >> @@ -2199,7 +2199,10 @@ int uvc_register_video_device(struct uvc_device *dev, >> break; >> } >> >> -strscpy(vdev->name, dev->name, sizeof(vdev->name)); >> +if (type == V4L2_BUF_TYPE_META_CAPTURE) >> +strscpy(vdev->name, "Metadata Videodev", sizeof(vdev->name)); >> +else >> +strscpy(vdev->name, dev->name, sizeof(vdev->name)); > > A UVC device could contain multiple output terminals (either in the same > chain or in different chains), which would still result in multiple > entities having the same name. Could this be fixed at the same time ? > You can use the unit ID of the output terminal to create unique names > (and it would be nice if the video and metadata nodes has similar names, > with "video" and "metadata" being the only difference between them). I agree with Laurent. How about using something like this for the videodevs: snprintf(vdev->name, sizeof(vdev->name), "Meta %s", dev->name); and: snprintf(vdev->name, sizeof(vdev->name), "Video %s", dev->name); Regards, Hans > >> >> /* >> * Set the driver data before calling video_register_device, otherwise >
Re: [External] Re: [PATCH v3 2/4] mm: memcontrol: make page_memcg{_rcu} only applicable for non-kmem page
On Thu, Mar 11, 2021 at 9:12 PM Johannes Weiner wrote:
>
> On Tue, Mar 09, 2021 at 06:07:15PM +0800, Muchun Song wrote:
> > We want to reuse the obj_cgroup APIs to charge the kmem pages.
> > If we do that, we should store an object cgroup pointer to
> > page->memcg_data for the kmem pages.
> >
> > Finally, page->memcg_data can have 3 different meanings.
> >
> > 1) For the slab pages, page->memcg_data points to an object cgroups
> > vector.
> >
> > 2) For the kmem pages (exclude the slab pages), page->memcg_data
> > points to an object cgroup.
> >
> > 3) For the user pages (e.g. the LRU pages), page->memcg_data points
> > to a memory cgroup.
> >
> > Currently we always get the memory cgroup associated with a page via
> > page_memcg() or page_memcg_rcu(). page_memcg_check() is special, it
> > has to be used in cases when it's not known if a page has an
> > associated memory cgroup pointer or an object cgroups vector. Because
> > the page->memcg_data of the kmem page is not pointing to a memory
> > cgroup in the later patch, the page_memcg() and page_memcg_rcu()
> > cannot be applicable for the kmem pages. In this patch, make
> > page_memcg() and page_memcg_rcu() no longer apply to the kmem pages.
> > We do not change the behavior of the page_memcg_check(), it is also
> > applicable for the kmem pages.
> >
> > In the end, there are 3 helpers to get the memcg associated with a page.
> > Usage is as follows.
> >
> > 1) Get the memory cgroup associated with a non-kmem page (e.g. the LRU
> > pages).
> >
> > - page_memcg()
> > - page_memcg_rcu()
> >
> > 2) Get the memory cgroup associated with a page. It has to be used in
> > cases when it's not known if a page has an associated memory cgroup
> > pointer or an object cgroups vector. Returns NULL for slab pages or
> > uncharged pages. Otherwise, returns memory cgroup for charged pages
> > (e.g. the kmem pages, the LRU pages).
> >
> > - page_memcg_check()
> >
> > In some place, we use page_memcg() to check whether the page is charged.
> > Now introduce page_memcg_charged() helper to do that.
> >
> > This is a preparation for reparenting the kmem pages.
> >
> > Signed-off-by: Muchun Song
>
> I'm pretty excited about the direction this series is taking us. The
> direct/raw pinning of memcgs from objects and allocations of various
> lifetimes has been causing chronic problems with dying cgroups piling
> up, consuming memory, and gumming up the works in everything that
> needs to iterate the cgroup tree (page reclaim comes to mind).
>
> The more allocation types we can convert to objcg, the better.
>
> This patch in particular looks mostly good to me too. Some comments
> inline:
Hi Johannes,
Very thanks for your suggestions. But I have some questions as below.
>
> > ---
> > include/linux/memcontrol.h | 33 +++--
> > mm/memcontrol.c| 23 +--
> > mm/page_alloc.c| 4 ++--
> > 3 files changed, 42 insertions(+), 18 deletions(-)
> >
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index e6dc793d587d..83cbcdcfcc92 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -358,14 +358,26 @@ enum page_memcg_data_flags {
> >
> > #define MEMCG_DATA_FLAGS_MASK (__NR_MEMCG_DATA_FLAGS - 1)
> >
> > +/* Return true for charged page, otherwise false. */
> > +static inline bool page_memcg_charged(struct page *page)
> > +{
> > + unsigned long memcg_data = page->memcg_data;
> > +
> > + VM_BUG_ON_PAGE(PageSlab(page), page);
> > + VM_BUG_ON_PAGE(memcg_data & MEMCG_DATA_OBJCGS, page);
> > +
> > + return !!memcg_data;
> > +}
>
> This is mosntly used right before a page_memcg_check(), which makes it
> somewhat redundant except for the VM_BUG_ON_PAGE() for slab pages.
Should I rename page_memcg_charged to page_memcg_raw?
And use page_memcg_raw to check whether the page is charged.
static inline bool page_memcg_charged(struct page *page)
{
return page->memcg_data;
}
>
> But it's also a bit of a confusing name: slab pages are charged too,
> but this function would crash if you called it on one.
>
> In light of this, and in light of what I wrote above about hopefully
> converting more and more allocations from raw memcg pins to
> reparentable objcg, it would be bettor to have
>
> page_memcg() for 1:1 page-memcg mappings, i.e. LRU & kmem
Sorry. I do not get the point. Because in the next patch, the kmem
page will use objcg to charge memory. So the page_memcg()
should not be suitable for the kmem pages. So I add a VM_BUG_ON
in the page_memcg() to catch invalid usage.
So I changed some page_memcg() calling to page_memcg_check()
in this patch, but you suggest using page_memcg(). I am very
confused. Are you worried about the extra overhead brought by calling
page_memcg_rcu()? In the next patch, I will remove page_memcg_check()
calling and use objcg APIs.
>
Re: [PATCH v2 4/6] media: uvcvideo: set error_idx to count on EACCESS
On 11/03/2021 23:19, Ricardo Ribalda wrote:
> According to the doc:
> The, in hindsight quite poor, solution for that is to set error_idx to
> count if the validation failed.
I think this needs a bit more explanation. How about this:
"If an error is found when validating the list of controls passed with
VIDIOC_G_EXT_CTRLS, then error_idx shall be set to ctrls->count to indicate
to userspace that no actual hardware was touched.
It would have been much nicer of course if error_idx could point to the
control index that failed the validation, but sadly that's not how the
API was designed."
>
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
> fail: v4l2-test-controls.cpp(645): invalid error index write
> only control
> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
>
> Signed-off-by: Ricardo Ribalda
After improving the commit log you can add my:
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/media/usb/uvc/uvc_v4l2.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 157310c0ca87..36eb48622d48 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1073,7 +1073,8 @@ static int uvc_ioctl_g_ext_ctrls(struct file *file,
> void *fh,
> ret = uvc_ctrl_get(chain, ctrl);
> if (ret < 0) {
> uvc_ctrl_rollback(handle);
> - ctrls->error_idx = i;
> + ctrls->error_idx = (ret == -EACCES) ?
> + ctrls->count : i;
> return ret;
> }
> }
>
Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files
On 12-03-21, 01:09, Frank Rowand wrote: > I suggested having the .dtso files include the .dts file because that is a > relatively > small and easy change to test. What would probably make more sense is the > rename > the existing overlay .dts files to be .dtso files and then for each overlay > .dtso > file create a new .dts file that #includes the corresponding .dtso file. > This is > more work and churn, but easier to document that the .dts files are a hack > that is > needed so that the corresponding .dtb.S files will be generated. What about creating links instead then ? -- viresh
Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files
On 3/12/21 1:03 AM, Frank Rowand wrote: > Hi Viresh, > > On 3/11/21 10:47 PM, Viresh Kumar wrote: >> On 10-03-21, 20:24, Masahiro Yamada wrote: >>> Even without "-I dts", >>> >>>inform = guess_input_format(arg, "dts"); >>> >>> seems to fall back to "dts" anyway, >>> but I guess you wanted to make this explicit, correct? >> >> +# Required for of unit-test files as they can't be renamed to .dtso >>> >>> If you go with *.dtso, I think you will rename >>> all *.dts under the drivers/ directory. >>> >>> What is blocking you from making this consistent? >> >> What about this patch instead ? This localizes the dts->dtbo hack to >> unitest's Makefile at least. > > It is late here, so I am not going to take the time to actually try what > I am going to suggest. I apologize in advance if I send you off on a > wild goose chase. > > Would it work to create a .dtso file for each of the unittest overlay .dts > files, where the .dtso would simply #include the .dts file. Then the > corresponding > .dtbo files could be added to the obj-$(CONFIG_OF_OVERLAY) list. I suggested having the .dtso files include the .dts file because that is a relatively small and easy change to test. What would probably make more sense is the rename the existing overlay .dts files to be .dtso files and then for each overlay .dtso file create a new .dts file that #includes the corresponding .dtso file. This is more work and churn, but easier to document that the .dts files are a hack that is needed so that the corresponding .dtb.S files will be generated. If it works, I am fine with either approach. -Frank > > I would like to avoid having the unitest-data/Makefile have different rules to > build objects because then the normal build rule is not being tested. > > -Frank > >> >> diff --git a/drivers/of/unittest-data/Makefile >> b/drivers/of/unittest-data/Makefile >> index a5d2d9254b2c..9f3426ec3fab 100644 >> --- a/drivers/of/unittest-data/Makefile >> +++ b/drivers/of/unittest-data/Makefile >> @@ -86,3 +86,7 @@ static_test_1-dtbs := static_base_1.dtb >> $(apply_static_overlay_1) >> static_test_2-dtbs := static_base_2.dtb $(apply_static_overlay_2) >> >> dtb-$(CONFIG_OF_OVERLAY) += static_test_1.dtb static_test_2.dtb >> + >> +# Required for of unittest files as they can't be renamed to .dtso >> +$(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE >> + $(call if_changed_dep,dtc) >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib >> index bc045a54a34e..77a9be055e51 100644 >> --- a/scripts/Makefile.lib >> +++ b/scripts/Makefile.lib >> @@ -347,7 +347,7 @@ cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x >> assembler-with-cpp -o $(dtc-tmp) $< ; >> $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE >> $(call if_changed_dep,dtc) >> >> -$(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE >> +$(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE >> $(call if_changed_dep,dtc) >> >> overlay-y := $(addprefix $(obj)/, $(overlay-y)) >> @@ -375,6 +375,9 @@ endef >> $(obj)/%.dt.yaml: $(src)/%.dts $(DTC) $(DT_TMP_SCHEMA) FORCE >> $(call if_changed_rule,dtc,yaml) >> >> +$(obj)/%.dt.yaml: $(src)/%.dtso $(DTC) $(DT_TMP_SCHEMA) FORCE >> + $(call if_changed_rule,dtc,yaml) >> + >> dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp) >> >> # Bzip2 >> >
Re: [PATCH V3 6/6] vDPA/ifcvf: verify mandatory feature bits for vDPA
On 3/12/2021 3:00 PM, Jason Wang wrote:
On 2021/3/12 2:40 下午, Zhu, Lingshan wrote:
On 3/12/2021 1:52 PM, Jason Wang wrote:
On 2021/3/11 3:19 下午, Zhu, Lingshan wrote:
On 3/11/2021 2:20 PM, Jason Wang wrote:
On 2021/3/11 12:16 下午, Zhu Lingshan wrote:
On 3/11/2021 11:20 AM, Jason Wang wrote:
On 2021/3/10 5:00 下午, Zhu Lingshan wrote:
vDPA requres VIRTIO_F_ACCESS_PLATFORM as a must, this commit
examines this when set features.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_base.c | 8
drivers/vdpa/ifcvf/ifcvf_base.h | 1 +
drivers/vdpa/ifcvf/ifcvf_main.c | 5 +
3 files changed, 14 insertions(+)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.c
b/drivers/vdpa/ifcvf/ifcvf_base.c
index ea6a78791c9b..58f47fdce385 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.c
+++ b/drivers/vdpa/ifcvf/ifcvf_base.c
@@ -224,6 +224,14 @@ u64 ifcvf_get_features(struct ifcvf_hw *hw)
return hw->hw_features;
}
+int ifcvf_verify_min_features(struct ifcvf_hw *hw)
+{
+ if (!(hw->hw_features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
+ return -EINVAL;
+
+ return 0;
+}
+
void ifcvf_read_net_config(struct ifcvf_hw *hw, u64 offset,
void *dst, int length)
{
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h
b/drivers/vdpa/ifcvf/ifcvf_base.h
index dbb8c10aa3b1..91c5735d4dc9 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -123,6 +123,7 @@ void io_write64_twopart(u64 val, u32 *lo,
u32 *hi);
void ifcvf_reset(struct ifcvf_hw *hw);
u64 ifcvf_get_features(struct ifcvf_hw *hw);
u64 ifcvf_get_hw_features(struct ifcvf_hw *hw);
+int ifcvf_verify_min_features(struct ifcvf_hw *hw);
u16 ifcvf_get_vq_state(struct ifcvf_hw *hw, u16 qid);
int ifcvf_set_vq_state(struct ifcvf_hw *hw, u16 qid, u16 num);
struct ifcvf_adapter *vf_to_adapter(struct ifcvf_hw *hw);
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c
b/drivers/vdpa/ifcvf/ifcvf_main.c
index 25fb9dfe23f0..f624f202447d 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -179,6 +179,11 @@ static u64 ifcvf_vdpa_get_features(struct
vdpa_device *vdpa_dev)
static int ifcvf_vdpa_set_features(struct vdpa_device
*vdpa_dev, u64 features)
{
struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ int ret;
+
+ ret = ifcvf_verify_min_features(vf);
So this validate device features instead of driver which is the
one we really want to check?
Thanks
Hi Jason,
Here we check device feature bits to make sure the device support
ACCESS_PLATFORM.
If you want to check device features, you need to do that during
probe() and fail the probing if without the feature. But I think
you won't ship cards without ACCESS_PLATFORM.
Yes, there are no reasons ship a card without ACCESS_PLATFORM
In get_features(),
it will return a intersection of device features bit and driver
supported features bits(which includes ACCESS_PLATFORM).
Other components like QEMU should not set features bits more than
this intersection of bits. so we can make sure if this
ifcvf_verify_min_features() passed, both device and driver
support ACCESS_PLATFORM.
Are you suggesting check driver feature bits in
ifcvf_verify_min_features() in the meantime as well?
So it really depends on your hardware. If you hardware can always
offer ACCESS_PLATFORM, you just need to check driver features.
This is how vdpa_sim and mlx5_vdpa work.
Yes, we always support ACCESS_PLATFORM, so it is hard coded in the
macro IFCVF_SUPPORTED_FEATURES.
That's not what I read from the code:
features = ifcvf_get_features(vf) & IFCVF_SUPPORTED_FEATURES;
ifcvf_get_features() reads device feature bits(which should always
has ACCSSS_PLATFORM) and IFCVF_SUPPORTED_FEATURES is the driver
supported feature bits
For "driver" you probably mean IFCVF. So there's some misunderstanding
before, what I meant for "driver" is virtio driver that do feature
negotaitation with the device.
I wonder what features are supported by the device but not the IFCVF
driver?
Thanks
we did not use TSO hardware feature bits in IFCVF driver for now.
Anyway, we will check the features bits to set in set_features than
hw/ifcvf driver feature bits.
THanks!
which hard coded ACCESS_PLATFORM, so the intersection should include
ACCESS_PLATFORM.
the intersection "features" is returned in get_features(), qemu
should set features according to it.
Now we check whether device support this feature bit as a double
conformation, are you suggesting we should check whether
ACCESS_PLATFORM & IFCVF_SUPPORTED_FEATURES
in set_features() as well?
If we know device will always offer ACCESS_PLATFORM, there's no need
to check it again. What we should check if whether driver set that,
and if it doesn't we need to fail set_features(). I think there's
little chance that IFCVF can work when IOMMU_PLATFORM is not
negotiated.
Agree, will check the features bit to set instead of device feature
bits. Thanks!
I prefer
[PATCH] net: ethernet: dec: tulip: Random spelling fixes throughout the file pnic2.c
Random spelling fixes throughout the file. Signed-off-by: Bhaskar Chowdhury --- drivers/net/ethernet/dec/tulip/pnic2.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/dec/tulip/pnic2.c b/drivers/net/ethernet/dec/tulip/pnic2.c index 412adaa7fdf8..04daffb8db2a 100644 --- a/drivers/net/ethernet/dec/tulip/pnic2.c +++ b/drivers/net/ethernet/dec/tulip/pnic2.c @@ -107,7 +107,7 @@ void pnic2_start_nway(struct net_device *dev) */ csr14 = (ioread32(ioaddr + CSR14) & 0xfff0ee39); -/* bit 17 - advetise 100baseTx-FD */ +/* bit 17 - advertise 100baseTx-FD */ if (tp->sym_advertise & 0x0100) csr14 |= 0x0002; /* bit 16 - advertise 100baseTx-HD */ @@ -116,7 +116,7 @@ void pnic2_start_nway(struct net_device *dev) /* bit 6 - advertise 10baseT-HD */ if (tp->sym_advertise & 0x0020) csr14 |= 0x0040; -/* Now set bit 12 Link Test Enable, Bit 7 Autonegotiation Enable +/* Now set bit 12 Link Test Enable, Bit 7 Auto negotiation Enable * and bit 0 Don't PowerDown 10baseT */ csr14 |= 0x1184; @@ -157,7 +157,7 @@ void pnic2_start_nway(struct net_device *dev) /* all set up so now force the negotiation to begin */ /* read in current values and mask off all but the -* Autonegotiation bits 14:12. Writing a 001 to those bits +* Auto negotiation bits 14:12. Writing a 001 to those bits * should start the autonegotiation */ csr12 = (ioread32(ioaddr + CSR12) & 0x8fff); @@ -290,7 +290,7 @@ void pnic2_lnk_change(struct net_device *dev, int csr5) csr14 = (ioread32(ioaddr + CSR14) & 0xff7f); iowrite32(csr14,ioaddr + CSR14); -/* what should we do when autonegotiate fails? +/* what should we do when auto negotiate fails? * should we try again or default to baseline * case. I just don't know. * -- 2.26.2
Re: [PATCH v2 3/6] media: uvcvideo: Return -EIO for control errors
On 11/03/2021 23:19, Ricardo Ribalda wrote: > The device is doing something unspected with the control. Either because > the protocol is not properly implemented or there has been a HW error. > > Fixes v4l2-compliance: > > Control ioctls (Input 0): > fail: v4l2-test-controls.cpp(448): s_ctrl returned an error > (22) > test VIDIOC_G/S_CTRL: FAIL > fail: v4l2-test-controls.cpp(698): s_ext_ctrls returned an > error (22) > test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL > > Signed-off-by: Ricardo Ribalda Reviewed-by: Hans Verkuil Thanks! Hans > --- > drivers/media/usb/uvc/uvc_video.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_video.c > b/drivers/media/usb/uvc/uvc_video.c > index f2f565281e63..25fd8aa23529 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -112,6 +112,11 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 > unit, > case 5: /* Invalid unit */ > case 6: /* Invalid control */ > case 7: /* Invalid Request */ > + /* > + * The firmware has not properly implemented > + * the control or there has been a HW error. > + */ > + return -EIO; > case 8: /* Invalid value within range */ > return -EINVAL; > default: /* reserved or unknown */ >
Re: [PATCH v2 2/6] media: uvcvideo: Set capability in s_param
On 11/03/2021 23:19, Ricardo Ribalda wrote:
> Fixes v4l2-compliance:
>
> Format ioctls (Input 0):
> warn: v4l2-test-formats.cpp(1339): S_PARM is supported but
> doesn't report V4L2_CAP_TIMEPERFRAME
> fail: v4l2-test-formats.cpp(1241): node->has_frmintervals &&
> !cap->capability
>
> Reviewed-by: Laurent Pinchart
Reviewed-by: Hans Verkuil
Thanks!
Hans
> Signed-off-by: Ricardo Ribalda
> ---
> drivers/media/usb/uvc/uvc_v4l2.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 252136cc885c..157310c0ca87 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -472,10 +472,13 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming
> *stream,
> uvc_simplify_fraction(,
> , 8, 333);
>
> - if (parm->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + if (parm->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> parm->parm.capture.timeperframe = timeperframe;
> - else
> + parm->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
> + } else {
> parm->parm.output.timeperframe = timeperframe;
> + parm->parm.output.capability = V4L2_CAP_TIMEPERFRAME;
> + }
>
> return 0;
> }
>
[syzbot] WARNING in huge_pmd_set_accessed
Hello, syzbot found the following issue on: HEAD commit:05a59d79 Merge git://git.kernel.org:/pub/scm/linux/kernel/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15b8820ad0 kernel config: https://syzkaller.appspot.com/x/.config?x=750735fdbc630971 dashboard link: https://syzkaller.appspot.com/bug?extid=edb1179c837e79cc2fc3 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+edb1179c837e79cc2...@syzkaller.appspotmail.com [ cut here ] raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 1 PID: 8400 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Modules linked in: CPU: 1 PID: 8400 Comm: syz-fuzzer Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Code: be ff cc cc cc cc cc cc cc cc cc cc cc 80 3d 11 d1 ad 04 00 74 01 c3 48 c7 c7 20 79 6b 89 c6 05 00 d1 ad 04 01 e8 75 5b be ff <0f> 0b c3 48 39 77 10 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 RSP: :c90001737ac8 EFLAGS: 00010282 RAX: RBX: 88801992a840 RCX: RDX: 8880223d0200 RSI: 815b4435 RDI: f520002e6f4b RBP: 0200 R08: R09: R10: 815ad19e R11: R12: 0003 R13: ed1003325508 R14: 0001 R15: 8880b9d36000 FS: 00c2e890() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 DR0: DR1: DR2: Call Trace: pv_wait arch/x86/include/asm/paravirt.h:564 [inline] pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 spin_lock include/linux/spinlock.h:354 [inline] pmd_lock include/linux/mm.h:2264 [inline] huge_pmd_set_accessed+0x103/0x320 mm/huge_memory.c:1265 handle_mm_fault+0x1bc/0x7e0 mm/memory.c:4549 handle_page_fault arch/x86/mm/fault.c:1475 [inline] exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1531 RIP: 0033:0x59072c Code: 48 8d 05 97 25 3e 00 48 89 44 24 08 e8 6d 54 ea ff 90 e8 07 a1 ed ff eb a5 cc cc cc cc cc 8b 44 24 10 48 8b 4c 24 08 89 41 24 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 48 8b RSP: 002b:00c0002e97b0 EFLAGS: 00010286 RAX: 4ef5 RBX: 4ef5 RCX: 00d85fe0 RBP: 00c0002e9890 R08: 4ef4 R09: 0059c5a0 R13: 00aa R14: 0093f064 R15: 0038 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH v2 1/2] usb: typec: tcpci: Add tcpc chip level callbacks
On Thu, Mar 11, 2021 at 10:34 PM Greg Kroah-Hartman wrote: > > On Fri, Mar 12, 2021 at 07:33:45AM +0100, Greg Kroah-Hartman wrote: > > On Thu, Mar 11, 2021 at 09:24:42PM -0800, Badhri Jagan Sridharan wrote: > > > This change adds chip callbacks for the following operations: > > > 1. Notifying port role > > > 2. Notifying orientation > > > > This should be 2 different patches, one per callback, right? > > > > And where is the code using these callbacks? We can't add any hooks > > without in-tree users, as you know. > > Ah, your second patch added that, sorry, missed it. > > This should be a 4 patch series, remember, only do one thing per patch. Sure. Will do in the next version. Thanks, Badhri > > thanks, > > greg k-h
Re: [PATCH v2 2/2] usb: typec: tcpci_maxim: configure charging & data paths
On Thu, Mar 11, 2021 at 10:39 PM Guenter Roeck wrote:
>
> On 3/11/21 9:24 PM, Badhri Jagan Sridharan wrote:
> > The change exposes the data_role and the orientation as a extcon
> > interface for configuring the USB data controller.
> >
> > Signed-off-by: Badhri Jagan Sridharan
> > ---
> > Changes since V1:
> > - Dropped changes related to get_/set_current_limit and pd_capable
> > callback. Will send them in as separate patches.
> > ---
> > drivers/usb/typec/tcpm/tcpci_maxim.c | 56
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c
> > b/drivers/usb/typec/tcpm/tcpci_maxim.c
> > index 041a1c393594..1210445713ee 100644
> > --- a/drivers/usb/typec/tcpm/tcpci_maxim.c
> > +++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
> > @@ -7,6 +7,8 @@
> >
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > @@ -46,6 +48,8 @@ struct max_tcpci_chip {
> > struct device *dev;
> > struct i2c_client *client;
> > struct tcpm_port *port;
> > + bool attached;
> > + struct extcon_dev *extcon;
> > };
> >
> > static const struct regmap_range max_tcpci_tcpci_range[] = {
> > @@ -439,6 +443,39 @@ static int tcpci_init(struct tcpci *tcpci, struct
> > tcpci_data *data)
> > return -1;
> > }
> >
> > +static void max_tcpci_set_roles(struct tcpci *tcpci, struct tcpci_data
> > *data, bool attached,
> > + enum typec_role role, enum typec_data_role
> > data_role)
> > +{
> > + struct max_tcpci_chip *chip = tdata_to_max_tcpci(data);
> > +
> > + chip->attached = attached;
> > +
> > + if (!attached) {
> > + extcon_set_state_sync(chip->extcon, EXTCON_USB_HOST, 0);
> > + extcon_set_state_sync(chip->extcon, EXTCON_USB, 0);
> > + return;
> > + }
> > +
> > + extcon_set_state_sync(chip->extcon, data_role == TYPEC_HOST ?
> > EXTCON_USB_HOST : EXTCON_USB,
> > + 1);
> > +}
> > +
> > +static void max_tcpci_set_cc_polarity(struct tcpci *tcpci, struct
> > tcpci_data *data,
> > + enum typec_cc_polarity polarity)
> > +{
> > + struct max_tcpci_chip *chip = tdata_to_max_tcpci(data);
> > +
> > + extcon_set_property(chip->extcon, EXTCON_USB,
> > EXTCON_PROP_USB_TYPEC_POLARITY,
> > + (union extcon_property_value)(int)polarity);
> > + extcon_set_property(chip->extcon, EXTCON_USB_HOST,
> > EXTCON_PROP_USB_TYPEC_POLARITY,
> > + (union extcon_property_value)(int)polarity);
> > +}
> > +
> > +static const unsigned int usbpd_extcon[] = {
> > + EXTCON_USB,
> > + EXTCON_USB_HOST,
> > +};
> > +
> > static int max_tcpci_probe(struct i2c_client *client, const struct
> > i2c_device_id *i2c_id)
> > {
> > int ret;
> > @@ -472,6 +509,8 @@ static int max_tcpci_probe(struct i2c_client *client,
> > const struct i2c_device_id
> > chip->data.auto_discharge_disconnect = true;
> > chip->data.vbus_vsafe0v = true;
> > chip->data.set_partner_usb_comm_capable =
> > max_tcpci_set_partner_usb_comm_capable;
> > + chip->data.set_roles = max_tcpci_set_roles;
> > + chip->data.set_cc_polarity = max_tcpci_set_cc_polarity;
> >
> > max_tcpci_init_regs(chip);
> > chip->tcpci = tcpci_register_port(chip->dev, >data);
> > @@ -484,6 +523,23 @@ static int max_tcpci_probe(struct i2c_client *client,
> > const struct i2c_device_id
> > if (ret < 0)
> > goto unreg_port;
> >
> > + chip->extcon = devm_extcon_dev_allocate(>dev, usbpd_extcon);
> > + if (IS_ERR(chip->extcon)) {
> > + dev_err(>dev, "Error allocating extcon: %ld\n",
> > PTR_ERR(chip->extcon));
> > + ret = PTR_ERR(chip->extcon);
> > + goto unreg_port;
> > + }
> > +
> > + ret = devm_extcon_dev_register(>dev, chip->extcon);
> > + if (ret < 0) {
> > + dev_err(>dev, "failed to register extcon device");
> > + goto unreg_port;
> > + }
>
> Effectively this mandates extcon support to be able to use this driver/chip.
> Does that make sense ? If this is indeed mandatory, how did it work so far ?
Hi Guenter,
We had this in our downstream branch but didnt get a chance to send it
to linux upstream.
I should wrap it in "if(IS_ENABLED(CONFIG_EXTCON))", the tcpc can work
without the
extcon.
>
> Also, what makes this code chip specific ?
Extcon here as is not chip code specific, but, the driver which
subscribes to the extcon interface is chip specific.
I hope it's ok to still send this.
Thanks,
Badhri
>
> Thanks,
> Guenter
>
> > +
> > + extcon_set_property_capability(chip->extcon, EXTCON_USB,
> > EXTCON_PROP_USB_TYPEC_POLARITY);
> > + extcon_set_property_capability(chip->extcon, EXTCON_USB_HOST,
> > +EXTCON_PROP_USB_TYPEC_POLARITY);
> > +
> > device_init_wakeup(chip->dev, true);
> >
RE: [PATCH 2/2] dm verity: allow only one verify mode
Hello, Dear Sami Tolvanen.
Thank you for reply.
> I agree that we shouldn't allow this, at least not without a warning, but
> out of curiosity, do you actually have a situation where this could happen?
> One ideally shouldn't be passing untrusted parameters to dm-verity.
Of course, I don't think this will happen because they are dm-verity experts.
But since we are humans, I think this case could happen accidentally.
So it would be a good at preventing these cases.
> I don't have a strong opinion about this, but the documentation doesn't
> talk about verity modes, so perhaps this could be reworded to something
> like "Conflicting error handling parameters"?
Yes of course. That looks better.
I also had some ambiguous about how to express it.
This is because I couldn't find it in document.
The code says verity mode, so I wrote it down. never mind it :)
like this)
case DM_VERITY_MODE_LOGGING:
case DM_VERITY_MODE_RESTART:
case DM_VERITY_MODE_PANIC:
> On Thu, Mar 11, 2021 at 4:19 AM JeongHyeon Lee
> wrote:
> >
> > If there are multiple verity mode when parsing the verity mode of dm
> > verity table, it will be set as the last one.
> > So set to 'allow only once' to prevent it.
>
> I agree that we shouldn't allow this, at least not without a warning, but
> out of curiosity, do you actually have a situation where this could happen?
> One ideally shouldn't be passing untrusted parameters to dm-verity.
>
> >
> > Signed-off-by: JeongHyeon Lee
> > ---
> > drivers/md/dm-verity-target.c | 38
> > ++-
> > 1 file changed, 28 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/md/dm-verity-target.c
> > b/drivers/md/dm-verity-target.c index 808a98ef624c..b76431dc7721
> > 100644
> > --- a/drivers/md/dm-verity-target.c
> > +++ b/drivers/md/dm-verity-target.c
> > @@ -893,6 +893,28 @@ static int verity_alloc_zero_digest(struct
> dm_verity *v)
> > return r;
> > }
> >
> > +static inline bool verity_is_verity_mode(const char *arg_name) {
> > + return (!strcasecmp(arg_name, DM_VERITY_OPT_LOGGING) ||
> > + !strcasecmp(arg_name, DM_VERITY_OPT_RESTART) ||
> > + !strcasecmp(arg_name, DM_VERITY_OPT_PANIC)); }
> > +
> > +static int verity_parse_verity_mode(struct dm_verity *v, const char
> > +*arg_name) {
> > + if (v->mode)
> > + return -EINVAL;
> > +
> > + if (!strcasecmp(arg_name, DM_VERITY_OPT_LOGGING))
> > + v->mode = DM_VERITY_MODE_LOGGING;
> > + else if (!strcasecmp(arg_name, DM_VERITY_OPT_RESTART))
> > + v->mode = DM_VERITY_MODE_RESTART;
> > + else if (!strcasecmp(arg_name, DM_VERITY_OPT_PANIC))
> > + v->mode = DM_VERITY_MODE_PANIC;
> > +
> > + return 0;
> > +}
> > +
> > static int verity_parse_opt_args(struct dm_arg_set *as, struct
> dm_verity *v,
> > struct dm_verity_sig_opts
> > *verify_args) { @@ -916,16 +938,12 @@ static int
> > verity_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,
> > arg_name = dm_shift_arg(as);
> > argc--;
> >
> > - if (!strcasecmp(arg_name, DM_VERITY_OPT_LOGGING)) {
> > - v->mode = DM_VERITY_MODE_LOGGING;
> > - continue;
> > -
> > - } else if (!strcasecmp(arg_name, DM_VERITY_OPT_RESTART)) {
> > - v->mode = DM_VERITY_MODE_RESTART;
> > - continue;
> > -
> > - } else if (!strcasecmp(arg_name, DM_VERITY_OPT_PANIC)) {
> > - v->mode = DM_VERITY_MODE_PANIC;
> > + if (verity_is_verity_mode(arg_name)) {
> > + r = verity_parse_verity_mode(v, arg_name);
> > + if (r) {
> > + ti->error = "Already verity mode set";
>
> I don't have a strong opinion about this, but the documentation doesn't
> talk about verity modes, so perhaps this could be reworded to something
> like "Conflicting error handling parameters"?
>
> > + return r;
> > + }
> > continue;
> >
> > } else if (!strcasecmp(arg_name,
> > DM_VERITY_OPT_IGN_ZEROES)) {
> > --
> > 2.17.1
> >
>
> Sami
Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files
Hi Viresh, On 3/11/21 10:47 PM, Viresh Kumar wrote: > On 10-03-21, 20:24, Masahiro Yamada wrote: >> Even without "-I dts", >> >>inform = guess_input_format(arg, "dts"); >> >> seems to fall back to "dts" anyway, >> but I guess you wanted to make this explicit, correct? > > >>> +# Required for of unit-test files as they can't be renamed to .dtso >> >> If you go with *.dtso, I think you will rename >> all *.dts under the drivers/ directory. >> >> What is blocking you from making this consistent? > > What about this patch instead ? This localizes the dts->dtbo hack to > unitest's Makefile at least. It is late here, so I am not going to take the time to actually try what I am going to suggest. I apologize in advance if I send you off on a wild goose chase. Would it work to create a .dtso file for each of the unittest overlay .dts files, where the .dtso would simply #include the .dts file. Then the corresponding .dtbo files could be added to the obj-$(CONFIG_OF_OVERLAY) list. I would like to avoid having the unitest-data/Makefile have different rules to build objects because then the normal build rule is not being tested. -Frank > > diff --git a/drivers/of/unittest-data/Makefile > b/drivers/of/unittest-data/Makefile > index a5d2d9254b2c..9f3426ec3fab 100644 > --- a/drivers/of/unittest-data/Makefile > +++ b/drivers/of/unittest-data/Makefile > @@ -86,3 +86,7 @@ static_test_1-dtbs := static_base_1.dtb > $(apply_static_overlay_1) > static_test_2-dtbs := static_base_2.dtb $(apply_static_overlay_2) > > dtb-$(CONFIG_OF_OVERLAY) += static_test_1.dtb static_test_2.dtb > + > +# Required for of unittest files as they can't be renamed to .dtso > +$(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE > + $(call if_changed_dep,dtc) > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index bc045a54a34e..77a9be055e51 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -347,7 +347,7 @@ cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x > assembler-with-cpp -o $(dtc-tmp) $< ; > $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE > $(call if_changed_dep,dtc) > > -$(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE > +$(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE > $(call if_changed_dep,dtc) > > overlay-y := $(addprefix $(obj)/, $(overlay-y)) > @@ -375,6 +375,9 @@ endef > $(obj)/%.dt.yaml: $(src)/%.dts $(DTC) $(DT_TMP_SCHEMA) FORCE > $(call if_changed_rule,dtc,yaml) > > +$(obj)/%.dt.yaml: $(src)/%.dtso $(DTC) $(DT_TMP_SCHEMA) FORCE > + $(call if_changed_rule,dtc,yaml) > + > dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp) > > # Bzip2 >
[rcu:dev.2021.03.08a] BUILD SUCCESS a7933665e0e3fad60118e141db9709d2cc1f42ed
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2021.03.08a branch HEAD: a7933665e0e3fad60118e141db9709d2cc1f42ed refscale: Add locking, both irqsave and otherwise elapsed time: 722m configs tested: 127 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arc defconfig arm mxs_defconfig sh secureedge5410_defconfig ia64 tiger_defconfig arm spitz_defconfig ia64 alldefconfig mips rt305x_defconfig arm mv78xx0_defconfig arm exynos_defconfig m68km5272c3_defconfig arm nhk8815_defconfig powerpc mpc836x_rdk_defconfig mipsqi_lb60_defconfig powerpc tqm8555_defconfig openrisc simple_smp_defconfig nds32alldefconfig powerpcsocrates_defconfig sh se7712_defconfig riscv defconfig arm collie_defconfig arm mainstone_defconfig powerpc eiger_defconfig mips pistachio_defconfig powerpc mpc866_ads_defconfig powerpc ep88xc_defconfig shsh7763rdp_defconfig armneponset_defconfig arm s3c6400_defconfig sh allmodconfig mipsnlm_xlr_defconfig powerpcge_imp3a_defconfig arm iop32x_defconfig sparc sparc32_defconfig shedosk7705_defconfig powerpc mpc836x_mds_defconfig armqcom_defconfig riscvalldefconfig powerpc taishan_defconfig powerpc mpc8315_rdb_defconfig arm corgi_defconfig arm eseries_pxa_defconfig mips rs90_defconfig armmini2440_defconfig powerpc tqm8560_defconfig powerpc iss476-smp_defconfig arm aspeed_g4_defconfig powerpc redwood_defconfig mipsmalta_qemu_32r6_defconfig mips ci20_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20210311 x86_64 randconfig-a001-20210311 x86_64 randconfig-a005-20210311 x86_64 randconfig-a002-20210311 x86_64 randconfig-a003-20210311 x86_64 randconfig-a004-20210311 i386 randconfig-a001-20210312 i386 randconfig-a005-20210312 i386 randconfig-a002-20210312 i386 randconfig-a003-20210312 i386 randconfig-a004-20210312 i386 randconfig-a006-20210312 i386 randconfig-a001-20210311 i386 randconfig-a005-20210311 i386 randconfig-a003-20210311 i386
Re: [RFC] scripts: kernel-doc: avoid warnings due to initial commented lines in file
On Thu, Mar 11, 2021 at 10:04 PM Aditya wrote:
>
> On 10/3/21 11:49 am, Lukas Bulwahn wrote:
> > On Tue, Mar 9, 2021 at 10:24 PM Aditya wrote:
> >>
> >> On 9/3/21 7:00 pm, Markus Heiser wrote:
> >>>
> >>> Am 09.03.21 um 13:53 schrieb Aditya Srivastava:
> Starting commented lines in a file mostly contains comments describing
> license, copyright or general information about the file.
>
> E.g., in sound/pci/ctxfi/ctresource.c, initial comment lines describe
> its copyright and other related file informations.
> >>>
> >>> The opening comment mark /** is used for kernel-doc comments [1]
> >>>
> >>> [1]
> >>> https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#how-to-format-kernel-doc-comments
> >>>
> >>
> >> Hi Markus!
> >> That's true. But the content inside the comment does not follow
> >> kernel-doc format.
> >> For e.g., try running kernel-doc -none/man/rst on the above file in
> >> the example("sound/pci/ctxfi/ctresource.c").
> >> The starting 2-3 lines in files generally do not contain any
> >> struct/enum/function, etc. declaration.
> >>
> >
> > Aditya, can you provide a diff of the warnings over the whole kernel tree?
> >
> > At the moment, your patch just implements ignoring the initial
> > comment, which probably is good for experimentation.
> >
> > Alternatively, we could simply have a dedicated warning and then
> > ignore it or even warn and then parse it as-if.
> >
> > In the "long run", we would probably want to fix all current files in
> > the repository by just replacing '/**' by '/*' and have kernel-doc
> > warn about this suspicious pattern, when new files appear (maybe even
> > configurable, but that is another feature to enable or disable certain
> > kernel-doc checks and warnings). I would certainly assist and
> > contribute to such a clean-up task.
> >
> > I think the first step is to look at the diff, and see how many cases
> > really appear in the tree... then check how many patches throughout
> > the whole tree are required and if they are generally accepted.
> >
>
> Hi Lukas!
> This is the diff of the warnings over kernel tree before and after
> applying these changes.
> There are 2 sections in this report:
> 1) for the warnings present before, but not after, and;
> 2) after but not before
>
> The part (2) contains, for some cases, where the warning for "warning:
> Incorrect use of kernel-doc format:" type has changed to "warning:
> wrong kernel-doc identifier on line:" type.
>
> The diff file can be found at:
> https://github.com/AdityaSrivast/kernel-tasks/blob/master/random/kernel-doc/avoid_init_line_diff.txt
>
Thanks, let us check if we can use this diff to create a patch set
that cleans up those header comments for those files.
Lukas
Re: [PATCH V3 6/6] vDPA/ifcvf: verify mandatory feature bits for vDPA
On 2021/3/12 2:40 下午, Zhu, Lingshan wrote:
On 3/12/2021 1:52 PM, Jason Wang wrote:
On 2021/3/11 3:19 下午, Zhu, Lingshan wrote:
On 3/11/2021 2:20 PM, Jason Wang wrote:
On 2021/3/11 12:16 下午, Zhu Lingshan wrote:
On 3/11/2021 11:20 AM, Jason Wang wrote:
On 2021/3/10 5:00 下午, Zhu Lingshan wrote:
vDPA requres VIRTIO_F_ACCESS_PLATFORM as a must, this commit
examines this when set features.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_base.c | 8
drivers/vdpa/ifcvf/ifcvf_base.h | 1 +
drivers/vdpa/ifcvf/ifcvf_main.c | 5 +
3 files changed, 14 insertions(+)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.c
b/drivers/vdpa/ifcvf/ifcvf_base.c
index ea6a78791c9b..58f47fdce385 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.c
+++ b/drivers/vdpa/ifcvf/ifcvf_base.c
@@ -224,6 +224,14 @@ u64 ifcvf_get_features(struct ifcvf_hw *hw)
return hw->hw_features;
}
+int ifcvf_verify_min_features(struct ifcvf_hw *hw)
+{
+ if (!(hw->hw_features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
+ return -EINVAL;
+
+ return 0;
+}
+
void ifcvf_read_net_config(struct ifcvf_hw *hw, u64 offset,
void *dst, int length)
{
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h
b/drivers/vdpa/ifcvf/ifcvf_base.h
index dbb8c10aa3b1..91c5735d4dc9 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -123,6 +123,7 @@ void io_write64_twopart(u64 val, u32 *lo,
u32 *hi);
void ifcvf_reset(struct ifcvf_hw *hw);
u64 ifcvf_get_features(struct ifcvf_hw *hw);
u64 ifcvf_get_hw_features(struct ifcvf_hw *hw);
+int ifcvf_verify_min_features(struct ifcvf_hw *hw);
u16 ifcvf_get_vq_state(struct ifcvf_hw *hw, u16 qid);
int ifcvf_set_vq_state(struct ifcvf_hw *hw, u16 qid, u16 num);
struct ifcvf_adapter *vf_to_adapter(struct ifcvf_hw *hw);
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c
b/drivers/vdpa/ifcvf/ifcvf_main.c
index 25fb9dfe23f0..f624f202447d 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -179,6 +179,11 @@ static u64 ifcvf_vdpa_get_features(struct
vdpa_device *vdpa_dev)
static int ifcvf_vdpa_set_features(struct vdpa_device
*vdpa_dev, u64 features)
{
struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ int ret;
+
+ ret = ifcvf_verify_min_features(vf);
So this validate device features instead of driver which is the
one we really want to check?
Thanks
Hi Jason,
Here we check device feature bits to make sure the device support
ACCESS_PLATFORM.
If you want to check device features, you need to do that during
probe() and fail the probing if without the feature. But I think
you won't ship cards without ACCESS_PLATFORM.
Yes, there are no reasons ship a card without ACCESS_PLATFORM
In get_features(),
it will return a intersection of device features bit and driver
supported features bits(which includes ACCESS_PLATFORM).
Other components like QEMU should not set features bits more than
this intersection of bits. so we can make sure if this
ifcvf_verify_min_features() passed, both device and driver support
ACCESS_PLATFORM.
Are you suggesting check driver feature bits in
ifcvf_verify_min_features() in the meantime as well?
So it really depends on your hardware. If you hardware can always
offer ACCESS_PLATFORM, you just need to check driver features. This
is how vdpa_sim and mlx5_vdpa work.
Yes, we always support ACCESS_PLATFORM, so it is hard coded in the
macro IFCVF_SUPPORTED_FEATURES.
That's not what I read from the code:
features = ifcvf_get_features(vf) & IFCVF_SUPPORTED_FEATURES;
ifcvf_get_features() reads device feature bits(which should always has
ACCSSS_PLATFORM) and IFCVF_SUPPORTED_FEATURES is the driver supported
feature bits
For "driver" you probably mean IFCVF. So there's some misunderstanding
before, what I meant for "driver" is virtio driver that do feature
negotaitation with the device.
I wonder what features are supported by the device but not the IFCVF driver?
Thanks
which hard coded ACCESS_PLATFORM, so the intersection should include
ACCESS_PLATFORM.
the intersection "features" is returned in get_features(), qemu should
set features according to it.
Now we check whether device support this feature bit as a double
conformation, are you suggesting we should check whether
ACCESS_PLATFORM & IFCVF_SUPPORTED_FEATURES
in set_features() as well?
If we know device will always offer ACCESS_PLATFORM, there's no need
to check it again. What we should check if whether driver set that,
and if it doesn't we need to fail set_features(). I think there's
little chance that IFCVF can work when IOMMU_PLATFORM is not negotiated.
Agree, will check the features bit to set instead of device feature
bits. Thanks!
I prefer check both device and IFCVF_SUPPORTED_FEATURES both, more
reliable.
So again, if you want to check device features, set_features() is not
the proper place. We need to fail the probe in this case.
Thanks
Thanks!
Re: [PATCH net-next v5 1/2] net: Add a WWAN subsystem
On Thu, Mar 11, 2021 at 09:41:03PM +0100, Loic Poulain wrote: > This change introduces initial support for a WWAN subsystem. Given the > complexity and heterogeneity of existing WWAN hardwares and interfaces, > there is no strict definition of what a WWAN device is and how it should > be represented. It's often a collection of multiple components/devices > that perform the global WWAN feature (netdev, tty, chardev, etc). > > One usual way to expose modem controls and configuration is via high > level protocols such as the well known AT command protocol, MBIM or > QMI. The USB modems started to expose that as character devices, and > user daemons such as ModemManager learnt how to deal with that. This > initial version adds the concept of WWAN port, which can be registered > by any driver to expose one of these protocols. The WWAN core takes > care of the generic part, including character device creation and lets > the driver implementing access (fops) to the selected protocol. > > Since the different components/devices do no necesserarly know about > each others, and can be created/removed in different orders, the > WWAN core ensures that devices being part of the same hardware are > also represented as a unique WWAN device, relying on the provided > parent device (e.g. mhi controller, USB device). It's a 'trick' I > copied from Johannes's earlier WWAN subsystem proposal. > > This initial version is purposely minimalist, it's essentially moving > the generic part of the previously proposed mhi_wwan_ctrl driver inside > a common WWAN framework, but the implementation is open and flexible > enough to allow extension for further drivers. > > Signed-off-by: Loic Poulain > --- > v2: not part of the series > v3: not part of the series > v4: Introduce WWAN framework/subsystem > v5: Specify WWAN_CORE module name in Kconfig > > drivers/net/Kconfig | 2 + > drivers/net/Makefile | 1 + > drivers/net/wwan/Kconfig | 22 +++ > drivers/net/wwan/Makefile| 8 +++ > drivers/net/wwan/wwan_core.c | 150 > +++ > drivers/net/wwan/wwan_core.h | 20 ++ > drivers/net/wwan/wwan_port.c | 136 +++ > include/linux/wwan.h | 121 ++ > 8 files changed, 460 insertions(+) > create mode 100644 drivers/net/wwan/Kconfig > create mode 100644 drivers/net/wwan/Makefile > create mode 100644 drivers/net/wwan/wwan_core.c > create mode 100644 drivers/net/wwan/wwan_core.h > create mode 100644 drivers/net/wwan/wwan_port.c > create mode 100644 include/linux/wwan.h > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index 260f9f4..ec00f92 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -500,6 +500,8 @@ source "drivers/net/wan/Kconfig" > > source "drivers/net/ieee802154/Kconfig" > > +source "drivers/net/wwan/Kconfig" > + > config XEN_NETDEV_FRONTEND > tristate "Xen network device frontend driver" > depends on XEN > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > index f4990ff..5da6424 100644 > --- a/drivers/net/Makefile > +++ b/drivers/net/Makefile > @@ -68,6 +68,7 @@ obj-$(CONFIG_SUNGEM_PHY) += sungem_phy.o > obj-$(CONFIG_WAN) += wan/ > obj-$(CONFIG_WLAN) += wireless/ > obj-$(CONFIG_IEEE802154) += ieee802154/ > +obj-$(CONFIG_WWAN) += wwan/ > > obj-$(CONFIG_VMXNET3) += vmxnet3/ > obj-$(CONFIG_XEN_NETDEV_FRONTEND) += xen-netfront.o > diff --git a/drivers/net/wwan/Kconfig b/drivers/net/wwan/Kconfig > new file mode 100644 > index 000..545fe54 > --- /dev/null > +++ b/drivers/net/wwan/Kconfig > @@ -0,0 +1,22 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# Wireless WAN device configuration > +# > + > +menuconfig WWAN > + bool "Wireless WAN" > + help > + This section contains Wireless WAN driver configurations. > + > +if WWAN > + > +config WWAN_CORE > + tristate "WWAN Driver Core" > + help > + Say Y here if you want to use the WWAN driver core. This driver > + provides a common framework for WWAN drivers. > + > + To compile this driver as a module, choose M here: the module will be > + called wwan. > + > +endif # WWAN > diff --git a/drivers/net/wwan/Makefile b/drivers/net/wwan/Makefile > new file mode 100644 > index 000..ca8bb5a > --- /dev/null > +++ b/drivers/net/wwan/Makefile > @@ -0,0 +1,8 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Makefile for the Linux WWAN device drivers. > +# > + > +obj-$(CONFIG_WWAN_CORE) += wwan.o > +wwan-objs += wwan_core.o wwan_port.o > + > diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c > new file mode 100644 > index 000..42ba6c0 > --- /dev/null > +++ b/drivers/net/wwan/wwan_core.c > @@ -0,0 +1,150 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* Copyright (c) 2021, Linaro Ltd */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include >
kmap_local semantics
So with the new kmap_local interface is it possible / advisable to use local kmaps over code that might schedule(), e.g. to wait for I/O?
[PATCH] gpio: mpc8xxx: Add ACPI support
Current implementation only supports DT, now add ACPI support.
Note that compared to device of 'fsl,qoriq-gpio', LS1028A and
LS1088A's GPIO have no extra programming, so simplify related checking.
Signed-off-by: Ran Wang
---
drivers/gpio/gpio-mpc8xxx.c | 50 +++--
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 6dfca83bcd90..de5b7e17cde3 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -9,6 +9,7 @@
* kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -292,8 +293,6 @@ static const struct of_device_id mpc8xxx_gpio_ids[] = {
{ .compatible = "fsl,mpc5121-gpio", .data = _gpio_devtype, },
{ .compatible = "fsl,mpc5125-gpio", .data = _gpio_devtype, },
{ .compatible = "fsl,pq3-gpio", },
- { .compatible = "fsl,ls1028a-gpio", },
- { .compatible = "fsl,ls1088a-gpio", },
{ .compatible = "fsl,qoriq-gpio", },
{}
};
@@ -303,10 +302,19 @@ static int mpc8xxx_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct mpc8xxx_gpio_chip *mpc8xxx_gc;
struct gpio_chip*gc;
- const struct mpc8xxx_gpio_devtype *devtype =
- of_device_get_match_data(>dev);
+ const struct mpc8xxx_gpio_devtype *devtype;
+ const struct acpi_device_id *acpi_id;
int ret;
+ if (pdev->dev.of_node) {
+ devtype = of_device_get_match_data(>dev);
+ } else {
+ acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
+ >dev);
+ if (acpi_id)
+ devtype = (struct mpc8xxx_gpio_devtype *)
acpi_id->driver_data;
+ }
+
mpc8xxx_gc = devm_kzalloc(>dev, sizeof(*mpc8xxx_gc), GFP_KERNEL);
if (!mpc8xxx_gc)
return -ENOMEM;
@@ -315,14 +323,14 @@ static int mpc8xxx_probe(struct platform_device *pdev)
raw_spin_lock_init(_gc->lock);
- mpc8xxx_gc->regs = of_iomap(np, 0);
+ mpc8xxx_gc->regs = devm_platform_ioremap_resource(pdev, 0);
if (!mpc8xxx_gc->regs)
return -ENOMEM;
gc = _gc->gc;
gc->parent = >dev;
- if (of_property_read_bool(np, "little-endian")) {
+ if (device_property_read_bool(>dev, "little-endian")) {
ret = bgpio_init(gc, >dev, 4,
mpc8xxx_gc->regs + GPIO_DAT,
NULL, NULL,
@@ -369,10 +377,14 @@ static int mpc8xxx_probe(struct platform_device *pdev)
* associated input enable must be set (GPIOxGPIE[IEn]=1) to propagate
* the port value to the GPIO Data Register.
*/
- if (of_device_is_compatible(np, "fsl,qoriq-gpio") ||
- of_device_is_compatible(np, "fsl,ls1028a-gpio") ||
- of_device_is_compatible(np, "fsl,ls1088a-gpio"))
- gc->write_reg(mpc8xxx_gc->regs + GPIO_IBE, 0x);
+ if (pdev->dev.of_node) {
+ if (of_device_is_compatible(np, "fsl,qoriq-gpio"))
+ gc->write_reg(mpc8xxx_gc->regs + GPIO_IBE, 0x);
+ } else {
+ if (acpi_match_device(pdev->dev.driver->acpi_match_table,
+ >dev))
+ gc->write_reg(mpc8xxx_gc->regs + GPIO_IBE, 0x);
+ }
ret = gpiochip_add_data(gc, mpc8xxx_gc);
if (ret) {
@@ -381,12 +393,15 @@ static int mpc8xxx_probe(struct platform_device *pdev)
goto err;
}
- mpc8xxx_gc->irqn = irq_of_parse_and_map(np, 0);
+ mpc8xxx_gc->irqn = platform_get_irq(pdev, 0);
if (!mpc8xxx_gc->irqn)
return 0;
- mpc8xxx_gc->irq = irq_domain_add_linear(np, MPC8XXX_GPIO_PINS,
- _gpio_irq_ops, mpc8xxx_gc);
+ mpc8xxx_gc->irq = irq_domain_create_linear(dev_fwnode(>dev),
+ MPC8XXX_GPIO_PINS,
+ _gpio_irq_ops,
+ mpc8xxx_gc);
+
if (!mpc8xxx_gc->irq)
return 0;
@@ -425,12 +440,21 @@ static int mpc8xxx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id gpio_acpi_ids[] = {
+ {"NXP0031",},
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, gpio_acpi_ids);
+#endif
+
static struct platform_driver mpc8xxx_plat_driver = {
.probe = mpc8xxx_probe,
.remove = mpc8xxx_remove,
.driver = {
.name = "gpio-mpc8xxx",
.of_match_table = mpc8xxx_gpio_ids,
+ .acpi_match_table = ACPI_PTR(gpio_acpi_ids),
},
};
--
2.25.1
Re: [PATCH v2 3/6] media: uvcvideo: Return -EIO for control errors
Hi Laurent On Fri, Mar 12, 2021 at 12:30 AM Laurent Pinchart wrote: > > Hi Ricardo, > > On Thu, Mar 11, 2021 at 11:59:27PM +0100, Ricardo Ribalda Delgado wrote: > > On Thu, Mar 11, 2021 at 11:53 PM Laurent Pinchart wrote: > > > On Thu, Mar 11, 2021 at 11:19:43PM +0100, Ricardo Ribalda wrote: > > > > The device is doing something unspected with the control. Either because > > > > the protocol is not properly implemented or there has been a HW error. > > > > > > > > Fixes v4l2-compliance: > > > > > > > > Control ioctls (Input 0): > > > > fail: v4l2-test-controls.cpp(448): s_ctrl returned an > > > > error (22) > > > > test VIDIOC_G/S_CTRL: FAIL > > > > fail: v4l2-test-controls.cpp(698): s_ext_ctrls returned > > > > an error (22) > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL > > > > > > > > Signed-off-by: Ricardo Ribalda > > > > > > The change looks good to me. > > > > > > Reviewed-by: Laurent Pinchart > > > > > > Which of the error codes below do you get with your camera, and for > > > which control ? > > > > Bus 001 Device 003: ID 05c8:03a2 Cheng Uei Precision Industry Co., Ltd > > (Foxlink) XiaoMi USB 2.0 Webcam > > > > info: checking extended control 'White Balance Temperature' (0x0098091a) > > Control error 7 > > info: checking extended control 'Exposure (Absolute)' (0x009a0902) > > Control error 6 > > :-S And what's the request (GET_CUR, GET_INFO, ...) ? Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). Failed to query (SET_CUR) UVC control 4 on unit 1: -32 (exp. 4) > > > > > --- > > > > drivers/media/usb/uvc/uvc_video.c | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c > > > > b/drivers/media/usb/uvc/uvc_video.c > > > > index f2f565281e63..25fd8aa23529 100644 > > > > --- a/drivers/media/usb/uvc/uvc_video.c > > > > +++ b/drivers/media/usb/uvc/uvc_video.c > > > > @@ -112,6 +112,11 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 > > > > query, u8 unit, > > > > case 5: /* Invalid unit */ > > > > case 6: /* Invalid control */ > > > > case 7: /* Invalid Request */ > > > > + /* > > > > + * The firmware has not properly implemented > > > > + * the control or there has been a HW error. > > > > + */ > > > > + return -EIO; > > > > case 8: /* Invalid value within range */ > > > > return -EINVAL; > > > > default: /* reserved or unknown */ > > -- > Regards, > > Laurent Pinchart -- Ricardo Ribalda
Re: [PATCH V11 0/5] dt: Add fdtoverlay rule and statically build unittest
On 3/11/21 10:31 PM, Viresh Kumar wrote: > On 11-03-21, 17:27, Frank Rowand wrote: >> On 3/9/21 11:35 PM, Viresh Kumar wrote: >>> Viresh Kumar (4): >>> kbuild: Simplify builds with CONFIG_OF_ALL_DTBS >>> kbuild: Allow .dtso format for overlay source files >>> of: unittest: Create overlay_common.dtsi and testcases_common.dtsi >>> of: unittest: Statically apply overlays using fdtoverlay >>> >>> drivers/of/unittest-data/Makefile | 48 ++ >>> drivers/of/unittest-data/overlay_base.dts | 90 +- >>> drivers/of/unittest-data/overlay_common.dtsi | 91 +++ >>> drivers/of/unittest-data/static_base_1.dts| 4 + >>> drivers/of/unittest-data/static_base_2.dts| 4 + >>> drivers/of/unittest-data/testcases.dts| 23 ++--- >>> .../of/unittest-data/testcases_common.dtsi| 19 >>> .../of/unittest-data/tests-interrupts.dtsi| 11 +-- >>> scripts/Makefile.lib | 40 ++-- >>> 9 files changed, 218 insertions(+), 112 deletions(-) >>> create mode 100644 drivers/of/unittest-data/overlay_common.dtsi >>> create mode 100644 drivers/of/unittest-data/static_base_1.dts >>> create mode 100644 drivers/of/unittest-data/static_base_2.dts >>> create mode 100644 drivers/of/unittest-data/testcases_common.dtsi >>> >>> >>> base-commit: a38fd8748464831584a19438cbb3082b5a2dab15 >>> >> >> Does not apply to 5.12-rc2 > > I was based right over the 5.12-rc2 tag. I don't know why I failed. Given your report, I went back to v5.12-rc2 and the patch series applies fine. Either way, my tags are ok. > >> because of a dependency on a patch to >> scripts/Makefile.lib. That patch has been merged by Linus >> somewhere between -rc2 and -rc3. > > git log --oneline v5.12-rc2..origin/master -- scripts/Makefile.lib > > gives no results to me. > >> I had a working version >> between -rc2 and -rc3 at commit e6f197677b2e > > I have tried both Linus' tree and linux-next, and I don't see this > commit. Sorry about that, the commit id I gave was after applying the patch series. The commit id I should have reported is 144c79ef3353. -Frank > >> that does have >> the required patch, so that is the version I used to test >> this series. >> >> There is still confusion caused by the contortions that unittest >> goes through to mis-use base DTBs vs overlay DTBs, so _after_ >> this series is merged by Rob, I will poke around and see if >> I can change unittest so that it does not look like it is >> mis-using DTBs and overlay DTBs. >> >> >> Reviewed-by: Frank Rowand >> Tested-by: Frank Rowand > > Thanks. >
[PATCH -tip v2 10/10] tracing: Remove kretprobe unknown indicator from stacktrace
Since the stacktrace API fixup the kretprobed address correctly,
there is no need to convert the "kretprobe_trampoline" to
"[unknown/kretprobe'd]" anymore. Remove it.
Signed-off-by: Masami Hiramatsu
Acked-by: Steven Rostedt (VMware)
---
kernel/trace/trace_output.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 61255bad7e01..f5f8b081b668 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -346,37 +346,18 @@ int trace_output_call(struct trace_iterator *iter, char
*name, char *fmt, ...)
}
EXPORT_SYMBOL_GPL(trace_output_call);
-#ifdef CONFIG_KRETPROBES
-static inline const char *kretprobed(const char *name)
-{
- static const char tramp_name[] = "kretprobe_trampoline";
- int size = sizeof(tramp_name);
-
- if (strncmp(tramp_name, name, size) == 0)
- return "[unknown/kretprobe'd]";
- return name;
-}
-#else
-static inline const char *kretprobed(const char *name)
-{
- return name;
-}
-#endif /* CONFIG_KRETPROBES */
-
void
trace_seq_print_sym(struct trace_seq *s, unsigned long address, bool offset)
{
#ifdef CONFIG_KALLSYMS
- char str[KSYM_SYMBOL_LEN];
- const char *name;
+ char name[KSYM_SYMBOL_LEN];
if (offset)
- sprint_symbol(str, address);
+ sprint_symbol(name, address);
else
- kallsyms_lookup(address, NULL, NULL, NULL, str);
- name = kretprobed(str);
+ kallsyms_lookup(address, NULL, NULL, NULL, name);
- if (name && strlen(name)) {
+ if (strlen(name)) {
trace_seq_puts(s, name);
return;
}
[PATCH -tip v2 09/10] x86/unwind/orc: Fixup kretprobe trampoline entry
Since the kretprobe replaces the function return address with
the kretprobe_trampoline on the stack, the ORC unwinder can not
continue the stack unwinding at that point.
To fix this issue, correct state->ip as like as function-graph
tracer in the unwind_next_frame().
Signed-off-by: Masami Hiramatsu
---
Changes in v2:
- Remove kretprobe wrapper functions from unwind_orc.c
- Do not fixup state->ip when unwinding with regs because
kretprobe fixup instruction pointer before calling handler.
---
arch/x86/include/asm/unwind.h |4
arch/x86/kernel/unwind_orc.c | 16
2 files changed, 20 insertions(+)
diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index 70fc159ebe69..ab5e45b848d5 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -20,6 +21,9 @@ struct unwind_state {
bool signal, full_regs;
unsigned long sp, bp, ip;
struct pt_regs *regs, *prev_regs;
+#if defined(CONFIG_KRETPROBES)
+ struct llist_node *kr_iter;
+#endif
#elif defined(CONFIG_UNWINDER_FRAME_POINTER)
bool got_irq;
unsigned long *bp, *orig_sp, ip;
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 2a1d47f47eee..1d1b9388a1b1 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -536,6 +537,21 @@ bool unwind_next_frame(struct unwind_state *state)
state->ip = ftrace_graph_ret_addr(state->task,
>graph_idx,
state->ip, (void *)ip_p);
+ /*
+* When the stack unwinder is called from the kretprobe handler
+* or the interrupt handler which occurs in the kretprobe
+* trampoline code, %sp is shown on the stack instead of the
+* return address because kretprobe_trampoline() does
+* "push %sp" at first.
+* And also the unwinder may find the kretprobe_trampoline
+* instead of the real return address on stack.
+* In those cases, find the correct return address from
+* task->kretprobe_instances list.
+*/
+ if (state->ip == sp ||
+ is_kretprobe_trampoline(state->ip))
+ state->ip = kretprobe_find_ret_addr(state->task,
+ >kr_iter);
state->sp = sp;
state->regs = NULL;
[PATCH -tip v2 07/10] ia64: Add instruction_pointer_set() API
Add instruction_pointer_set() API for ia64.
Signed-off-by: Masami Hiramatsu
---
arch/ia64/include/asm/ptrace.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/ia64/include/asm/ptrace.h b/arch/ia64/include/asm/ptrace.h
index b3aa46090101..dbd9e85cbc77 100644
--- a/arch/ia64/include/asm/ptrace.h
+++ b/arch/ia64/include/asm/ptrace.h
@@ -71,6 +71,12 @@ static inline long regs_return_value(struct pt_regs *regs)
return -regs->r8;
}
+static inline void instruction_pointer_set(struct pt_regs *regs, unsigned long
val)
+{
+ ia64_psr(regs)->ri = (val & 0xf);
+ regs->cr_iip = (val & ~0xfULL);
+}
+
/* Conserve space in histogram by encoding slot bits in address
* bits 2 and 3 rather than bits 0 and 1.
*/
Re: arm64 syzbot instances
On Thu, Mar 11, 2021 at 6:25 PM Dmitry Vyukov wrote: > > On Thu, Mar 11, 2021 at 2:30 PM Arnd Bergmann wrote: > > > > On Thu, Mar 11, 2021 at 12:38 PM Dmitry Vyukov wrote: > > > > > > The instances found few arm64-specific issues that we have not > > > observed on other instances: > > > > I've had a brief look at these: > > > > > https://syzkaller.appspot.com/bug?id=1d22a2cc3521d5cf6b41bd6b825793c2015f861f > > > > This one doesn't seem arm64 specific at all. While the KASAN report has > > shown > > up on arm64, the link to > > https://syzkaller.appspot.com/bug?id=aa8808729c0a3540e6a29f0d45394665caf79dca > > seems to be for x86 machines running into the same problem. > > You are right. It's probably a consequence of some configs being enabled. > I think we need to enable CONFIG_FW_LOADER_USER_HELPER on x86_64 > upstream instances as well. > > > > Looking deeper into the log, I see that fw_load_sysfs_fallback() finds > > an existing > > list entry on the global "pending_fw_head" list, which seems to have been > > freed > > earlier (the allocation listed here is not for a firmware load, so > > presumably it > > was recycled in the meantime). The log shows that this is the second time > > that > > loading the regulatory database failed in that run, so my guess is that it > > was > > the first failed load that left the freed firmware private data on the > > list, but I > > don't see how that happened. > > Can it be as simple as: fw_load_sysfs_fallback adds fw to the pending > list, but then returns with an error w/o removing it from the list? > There are some errors checks after that: > https://elixir.bootlin.com/linux/v5.12-rc2/source/drivers/base/firmware_loader/fallback.c#L536 > and it seems that the caller deletes fw in this case: > https://elixir.bootlin.com/linux/v5.12-rc2/source/drivers/base/firmware_loader/main.c#L839 I've enabled CONFIG_FW_LOADER_USER_HELPER for all instances and syzbot come up with a repro and KASAN report with alloc/free stacks: https://lore.kernel.org/lkml/af467105bd512...@google.com/
[PATCH -tip v2 08/10] kprobes: Setup instruction pointer in __kretprobe_trampoline_handler
To simplify the stacktrace with pt_regs from kretprobe handler,
set the correct return address to the instruction pointer in
the pt_regs before calling kretprobe handlers.
Suggested-by: Josh Poimboeuf
Signed-off-by: Masami Hiramatsu
---
kernel/kprobes.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2550521ff64d..51d0057382a5 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1897,6 +1897,9 @@ unsigned long __kretprobe_trampoline_handler(struct
pt_regs *regs,
BUG_ON(1);
}
+ /* Set the instruction pointer to the correct address */
+ instruction_pointer_set(regs, correct_ret_addr);
+
/* Run them. */
first = current->kretprobe_instances.first;
while (first) {
[PATCH -tip v2 06/10] ARC: Add instruction_pointer_set() API
Add instruction_pointer_set() API for arc.
Signed-off-by: Masami Hiramatsu
---
arch/arc/include/asm/ptrace.h |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
index 4c3c9be5bd16..cca8d6583e31 100644
--- a/arch/arc/include/asm/ptrace.h
+++ b/arch/arc/include/asm/ptrace.h
@@ -149,6 +149,11 @@ static inline long regs_return_value(struct pt_regs *regs)
return (long)regs->r0;
}
+static inline void instruction_pointer_set(struct pt_regs *regs,
+ unsigned long val)
+{
+ instruction_pointer(regs) = val;
+}
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PTRACE_H */
[PATCH -tip v2 04/10] kprobes: stacktrace: Recover the address changed by kretprobe
Recover the return address on the stack which changed by the
kretprobe. Note that this does not recover the address on the
!current stack trace if CONFIG_ARCH_STACKWALK=n because old
stack trace interface doesn't lock the stack in the generic
stack_trace_save*() functions.
So with this patch, ftrace correctly shows the stacktrace
as below;
# echo r vfs_read > kprobe_events
# echo stacktrace > events/kprobes/r_vfs_read_0/trigger
# echo 1 > events/kprobes/r_vfs_read_0/enable
# echo 1 > options/sym-offset
# less trace
...
sh-132 [007] ...122.524917:
=> kretprobe_dispatcher+0x7d/0xc0
=> __kretprobe_trampoline_handler+0xdb/0x1b0
=> trampoline_handler+0x48/0x60
=> kretprobe_trampoline+0x2a/0x50
=> ksys_read+0x70/0xf0
=> __x64_sys_read+0x1a/0x20
=> do_syscall_64+0x38/0x50
=> entry_SYSCALL_64_after_hwframe+0x44/0xae
=> 0
The trampoline_handler+0x48 is actual call site address,
not modified by kretprobe.
Reported-by: Daniel Xu
Signed-off-by: Masami Hiramatsu
---
Changes in v2:
- Add is_kretprobe_trampoline() for checking address outside of
kretprobe_find_ret_addr()
- Remove unneeded addr from kretprobe_find_ret_addr()
- Rename fixup_kretprobe_tramp_addr() to fixup_kretprobe_trampoline()
---
include/linux/kprobes.h | 22 ++
kernel/kprobes.c| 73 ++-
kernel/stacktrace.c | 22 ++
3 files changed, 91 insertions(+), 26 deletions(-)
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 65dadd4238a2..674b5adad281 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -215,6 +215,14 @@ static nokprobe_inline void
*kretprobe_trampoline_addr(void)
return dereference_function_descriptor(kretprobe_trampoline);
}
+static nokprobe_inline bool is_kretprobe_trampoline(unsigned long addr)
+{
+ return (void *)addr == kretprobe_trampoline_addr();
+}
+
+unsigned long kretprobe_find_ret_addr(struct task_struct *tsk,
+ struct llist_node **cur);
+
/* If the trampoline handler called from a kprobe, use this version */
unsigned long __kretprobe_trampoline_handler(struct pt_regs *regs,
void *frame_pointer);
@@ -514,6 +522,20 @@ static inline bool is_kprobe_optinsn_slot(unsigned long
addr)
}
#endif
+#if !defined(CONFIG_KRETPROBES)
+static nokprobe_inline bool is_kretprobe_trampoline(unsigned long addr)
+{
+ return false;
+}
+
+static nokprobe_inline
+unsigned long kretprobe_find_ret_addr(struct task_struct *tsk,
+ struct llist_node **cur)
+{
+ return 0;
+}
+#endif
+
/* Returns true if kprobes handled the fault */
static nokprobe_inline bool kprobe_page_fault(struct pt_regs *regs,
unsigned int trap)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 75c0a58c19c2..2550521ff64d 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1858,45 +1858,51 @@ static struct notifier_block kprobe_exceptions_nb = {
#ifdef CONFIG_KRETPROBES
-unsigned long __kretprobe_trampoline_handler(struct pt_regs *regs,
-void *frame_pointer)
+/* This assumes the tsk is current or the task which is not running. */
+unsigned long kretprobe_find_ret_addr(struct task_struct *tsk,
+ struct llist_node **cur)
{
- kprobe_opcode_t *correct_ret_addr = NULL;
struct kretprobe_instance *ri = NULL;
- struct llist_node *first, *node;
- struct kretprobe *rp;
+ struct llist_node *node = *cur;
+
+ if (!node)
+ node = tsk->kretprobe_instances.first;
+ else
+ node = node->next;
- /* Find all nodes for this frame. */
- first = node = current->kretprobe_instances.first;
while (node) {
ri = container_of(node, struct kretprobe_instance, llist);
-
- BUG_ON(ri->fp != frame_pointer);
-
if (ri->ret_addr != kretprobe_trampoline_addr()) {
- correct_ret_addr = ri->ret_addr;
- /*
-* This is the real return address. Any other
-* instances associated with this task are for
-* other calls deeper on the call stack
-*/
- goto found;
+ *cur = node;
+ return (unsigned long)ri->ret_addr;
}
-
node = node->next;
}
- pr_err("Oops! Kretprobe fails to find correct return address.\n");
- BUG_ON(1);
+ return 0;
+}
+NOKPROBE_SYMBOL(kretprobe_find_ret_addr);
-found:
- /* Unlink all nodes for this frame. */
- current->kretprobe_instances.first = node->next;
- node->next = NULL;
+unsigned long __kretprobe_trampoline_handler(struct pt_regs
[PATCH -tip v2 05/10] x86/kprobes: Add UNWIND_HINT_FUNC on kretprobe_trampoline code
From: Josh Poimboeuf Add UNWIND_HINT_FUNC on kretporbe_trampoline code so that ORC information is generated on the kretprobe_trampoline correctly. Signed-off-by: Josh Poimboeuf --- [MH] Add patch description. --- arch/x86/include/asm/unwind_hints.h |5 + arch/x86/kernel/kprobes/core.c |3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/unwind_hints.h b/arch/x86/include/asm/unwind_hints.h index 8e574c0afef8..8b33674288ea 100644 --- a/arch/x86/include/asm/unwind_hints.h +++ b/arch/x86/include/asm/unwind_hints.h @@ -52,6 +52,11 @@ UNWIND_HINT sp_reg=ORC_REG_SP sp_offset=8 type=UNWIND_HINT_TYPE_FUNC .endm +#else + +#define UNWIND_HINT_FUNC \ + UNWIND_HINT(ORC_REG_SP, 8, UNWIND_HINT_TYPE_FUNC, 0) + #endif /* __ASSEMBLY__ */ #endif /* _ASM_X86_UNWIND_HINTS_H */ diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index 3c00b773fe2e..e079eb487ecd 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -1023,6 +1023,7 @@ asm( /* We don't bother saving the ss register */ #ifdef CONFIG_X86_64 " pushq %rsp\n" + UNWIND_HINT_FUNC " pushfq\n" SAVE_REGS_STRING " movq %rsp, %rdi\n" @@ -1033,6 +1034,7 @@ asm( " popfq\n" #else " pushl %esp\n" + UNWIND_HINT_FUNC " pushfl\n" SAVE_REGS_STRING " movl %esp, %eax\n" @@ -1046,7 +1048,6 @@ asm( ".size kretprobe_trampoline, .-kretprobe_trampoline\n" ); NOKPROBE_SYMBOL(kretprobe_trampoline); -STACK_FRAME_NON_STANDARD(kretprobe_trampoline); /*
[PATCH -tip v2 03/10] kprobes: treewide: Remove trampoline_address from kretprobe_trampoline_handler()
Remove trampoline_address from kretprobe_trampoline_handler().
Instead of passing the address, kretprobe_trampoline_handler()
can use new kretprobe_trampoline_addr().
Signed-off-by: Masami Hiramatsu
---
Changes in v2:
- Remove arch_deref_entry_point() from comment.
---
arch/arc/kernel/kprobes.c |2 +-
arch/arm/probes/kprobes/core.c |3 +--
arch/arm64/kernel/probes/kprobes.c |3 +--
arch/csky/kernel/probes/kprobes.c |2 +-
arch/ia64/kernel/kprobes.c |5 ++---
arch/mips/kernel/kprobes.c |3 +--
arch/parisc/kernel/kprobes.c |4 ++--
arch/powerpc/kernel/kprobes.c |2 +-
arch/riscv/kernel/probes/kprobes.c |2 +-
arch/s390/kernel/kprobes.c |2 +-
arch/sh/kernel/kprobes.c |2 +-
arch/sparc/kernel/kprobes.c|2 +-
arch/x86/kernel/kprobes/core.c |2 +-
include/linux/kprobes.h| 18 +-
kernel/kprobes.c |3 +--
15 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/arch/arc/kernel/kprobes.c b/arch/arc/kernel/kprobes.c
index cabef45f11df..3ae01bb5820c 100644
--- a/arch/arc/kernel/kprobes.c
+++ b/arch/arc/kernel/kprobes.c
@@ -397,7 +397,7 @@ void __kprobes arch_prepare_kretprobe(struct
kretprobe_instance *ri,
static int __kprobes trampoline_probe_handler(struct kprobe *p,
struct pt_regs *regs)
{
- regs->ret = __kretprobe_trampoline_handler(regs, _trampoline,
NULL);
+ regs->ret = __kretprobe_trampoline_handler(regs, NULL);
/* By returning a non zero value, we are telling the kprobe handler
* that we don't want the post_handler to run
diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index a9653117ca0d..1782b41df095 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -413,8 +413,7 @@ void __naked __kprobes kretprobe_trampoline(void)
/* Called from kretprobe_trampoline */
static __used __kprobes void *trampoline_handler(struct pt_regs *regs)
{
- return (void *)kretprobe_trampoline_handler(regs, _trampoline,
- (void *)regs->ARM_fp);
+ return (void *)kretprobe_trampoline_handler(regs, (void *)regs->ARM_fp);
}
void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
diff --git a/arch/arm64/kernel/probes/kprobes.c
b/arch/arm64/kernel/probes/kprobes.c
index 66aac2881ba8..fce681fdfce6 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -412,8 +412,7 @@ int __init arch_populate_kprobe_blacklist(void)
void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
{
- return (void *)kretprobe_trampoline_handler(regs, _trampoline,
- (void *)kernel_stack_pointer(regs));
+ return (void *)kretprobe_trampoline_handler(regs, (void
*)kernel_stack_pointer(regs));
}
void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
diff --git a/arch/csky/kernel/probes/kprobes.c
b/arch/csky/kernel/probes/kprobes.c
index 589f090f48b9..cc589bc11904 100644
--- a/arch/csky/kernel/probes/kprobes.c
+++ b/arch/csky/kernel/probes/kprobes.c
@@ -404,7 +404,7 @@ int __init arch_populate_kprobe_blacklist(void)
void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
{
- return (void *)kretprobe_trampoline_handler(regs,
_trampoline, NULL);
+ return (void *)kretprobe_trampoline_handler(regs, NULL);
}
void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
diff --git a/arch/ia64/kernel/kprobes.c b/arch/ia64/kernel/kprobes.c
index 15871eb170c0..a008df8e7203 100644
--- a/arch/ia64/kernel/kprobes.c
+++ b/arch/ia64/kernel/kprobes.c
@@ -392,14 +392,13 @@ static void __kprobes set_current_kprobe(struct kprobe *p,
__this_cpu_write(current_kprobe, p);
}
-static void kretprobe_trampoline(void)
+void kretprobe_trampoline(void)
{
}
int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
{
- regs->cr_iip = __kretprobe_trampoline_handler(regs,
- dereference_function_descriptor(kretprobe_trampoline), NULL);
+ regs->cr_iip = __kretprobe_trampoline_handler(regs, NULL);
/*
* By returning a non-zero value, we are telling
* kprobe_handler() that we don't want the post_handler
diff --git a/arch/mips/kernel/kprobes.c b/arch/mips/kernel/kprobes.c
index 54dfba8fa77c..001a2f07ef44 100644
--- a/arch/mips/kernel/kprobes.c
+++ b/arch/mips/kernel/kprobes.c
@@ -489,8 +489,7 @@ void __kprobes arch_prepare_kretprobe(struct
kretprobe_instance *ri,
static int __kprobes trampoline_probe_handler(struct kprobe *p,
struct pt_regs *regs)
{
- instruction_pointer(regs) = __kretprobe_trampoline_handler(regs,
- kretprobe_trampoline, NULL);
+
[PATCH -tip v2 02/10] kprobes: treewide: Replace arch_deref_entry_point() with dereference_function_descriptor()
Replace arch_deref_entry_point() with dereference_function_descriptor()
because those are doing same thing.
Signed-off-by: Masami Hiramatsu
---
arch/ia64/kernel/kprobes.c|5 -
arch/powerpc/kernel/kprobes.c | 11 ---
include/linux/kprobes.h |1 -
kernel/kprobes.c |7 +--
lib/error-inject.c|3 ++-
5 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/ia64/kernel/kprobes.c b/arch/ia64/kernel/kprobes.c
index 006fbc1d7ae9..15871eb170c0 100644
--- a/arch/ia64/kernel/kprobes.c
+++ b/arch/ia64/kernel/kprobes.c
@@ -907,11 +907,6 @@ int __kprobes kprobe_exceptions_notify(struct
notifier_block *self,
return ret;
}
-unsigned long arch_deref_entry_point(void *entry)
-{
- return ((struct fnptr *)entry)->ip;
-}
-
static struct kprobe trampoline_p = {
.pre_handler = trampoline_probe_handler
};
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 01ab2163659e..eb0460949e1b 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -539,17 +539,6 @@ int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
}
NOKPROBE_SYMBOL(kprobe_fault_handler);
-unsigned long arch_deref_entry_point(void *entry)
-{
-#ifdef PPC64_ELF_ABI_v1
- if (!kernel_text_address((unsigned long)entry))
- return ppc_global_function_entry(entry);
- else
-#endif
- return (unsigned long)entry;
-}
-NOKPROBE_SYMBOL(arch_deref_entry_point);
-
static struct kprobe trampoline_p = {
.addr = (kprobe_opcode_t *) _trampoline,
.pre_handler = trampoline_probe_handler
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 1883a4a9f16a..d65c041b5c22 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -390,7 +390,6 @@ int register_kprobe(struct kprobe *p);
void unregister_kprobe(struct kprobe *p);
int register_kprobes(struct kprobe **kps, int num);
void unregister_kprobes(struct kprobe **kps, int num);
-unsigned long arch_deref_entry_point(void *);
int register_kretprobe(struct kretprobe *rp);
void unregister_kretprobe(struct kretprobe *rp);
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 745f08fdd7a6..2913de07f4a3 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1856,11 +1856,6 @@ static struct notifier_block kprobe_exceptions_nb = {
.priority = 0x7fff /* we need to be notified first */
};
-unsigned long __weak arch_deref_entry_point(void *entry)
-{
- return (unsigned long)entry;
-}
-
#ifdef CONFIG_KRETPROBES
unsigned long __kretprobe_trampoline_handler(struct pt_regs *regs,
@@ -2324,7 +2319,7 @@ static int __init populate_kprobe_blacklist(unsigned long
*start,
int ret;
for (iter = start; iter < end; iter++) {
- entry = arch_deref_entry_point((void *)*iter);
+ entry = (unsigned long)dereference_function_descriptor((void
*)*iter);
ret = kprobe_add_ksym_blacklist(entry);
if (ret == -EINVAL)
continue;
diff --git a/lib/error-inject.c b/lib/error-inject.c
index c73651b15b76..f71875ac5f9f 100644
--- a/lib/error-inject.c
+++ b/lib/error-inject.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/* Whitelist of symbols that can be overridden for error injection. */
static LIST_HEAD(error_injection_list);
@@ -64,7 +65,7 @@ static void populate_error_injection_list(struct
error_injection_entry *start,
mutex_lock(_mutex);
for (iter = start; iter < end; iter++) {
- entry = arch_deref_entry_point((void *)iter->addr);
+ entry = (unsigned long)dereference_function_descriptor((void
*)iter->addr);
if (!kernel_text_address(entry) ||
!kallsyms_lookup_size_offset(entry, , )) {
[PATCH -tip v2 01/10] ia64: kprobes: Fix to pass correct trampoline address to the handler
Commit e792ff804f49 ("ia64: kprobes: Use generic kretprobe trampoline handler")
missed to pass the wrong trampoline address (it passes the descriptor address
instead of function entry address).
This fixes it to pass correct trampoline address to
__kretprobe_trampoline_handler().
This also changes to use correct symbol dereference function to get the
function address from the kretprobe_trampoline.
Fixes: e792ff804f49 ("ia64: kprobes: Use generic kretprobe trampoline handler")
Signed-off-by: Masami Hiramatsu
---
arch/ia64/kernel/kprobes.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/kernel/kprobes.c b/arch/ia64/kernel/kprobes.c
index fc1ff8a4d7de..006fbc1d7ae9 100644
--- a/arch/ia64/kernel/kprobes.c
+++ b/arch/ia64/kernel/kprobes.c
@@ -398,7 +398,8 @@ static void kretprobe_trampoline(void)
int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
{
- regs->cr_iip = __kretprobe_trampoline_handler(regs,
kretprobe_trampoline, NULL);
+ regs->cr_iip = __kretprobe_trampoline_handler(regs,
+ dereference_function_descriptor(kretprobe_trampoline), NULL);
/*
* By returning a non-zero value, we are telling
* kprobe_handler() that we don't want the post_handler
@@ -414,7 +415,7 @@ void __kprobes arch_prepare_kretprobe(struct
kretprobe_instance *ri,
ri->fp = NULL;
/* Replace the return addr with trampoline addr */
- regs->b0 = ((struct fnptr *)kretprobe_trampoline)->ip;
+ regs->b0 = (unsigned
long)dereference_function_descriptor(kretprobe_trampoline);
}
/* Check the instruction in the slot is break */
@@ -918,14 +919,14 @@ static struct kprobe trampoline_p = {
int __init arch_init_kprobes(void)
{
trampoline_p.addr =
- (kprobe_opcode_t *)((struct fnptr *)kretprobe_trampoline)->ip;
+ dereference_function_description(kretprobe_trampoline);
return register_kprobe(_p);
}
int __kprobes arch_trampoline_kprobe(struct kprobe *p)
{
if (p->addr ==
- (kprobe_opcode_t *)((struct fnptr *)kretprobe_trampoline)->ip)
+ dereference_function_descriptor(kretprobe_trampoline))
return 1;
return 0;
[PATCH -tip v2 00/10] kprobes: Fix stacktrace with kretprobes
Hello, Here is the 2nd version of the series to fix the stacktrace with kretprobe. The 1st series is here; https://lore.kernel.org/bpf/161495873696.346821.10161501768906432924.stgit@devnote2/ In this version I merged the ORC unwinder fix for kretprobe which discussed in the previous thread. [3/10] is updated according to the Miroslav's comment. [4/10] is updated for simplify the code. [5/10]-[9/10] are discussed in the previsous tread and are introduced to the series. Daniel, can you also test this again? I and Josh discussed a bit different method and I've implemented it on this version. This actually changes the kretprobe behavisor a bit, now the instraction pointer in the pt_regs passed to kretprobe user handler is correctly set the real return address. So user handlers can get it via instruction_pointer() API. Thank you, --- Josh Poimboeuf (1): x86/kprobes: Add UNWIND_HINT_FUNC on kretprobe_trampoline code Masami Hiramatsu (9): ia64: kprobes: Fix to pass correct trampoline address to the handler kprobes: treewide: Replace arch_deref_entry_point() with dereference_function_descriptor() kprobes: treewide: Remove trampoline_address from kretprobe_trampoline_handler() kprobes: stacktrace: Recover the address changed by kretprobe ARC: Add instruction_pointer_set() API ia64: Add instruction_pointer_set() API kprobes: Setup instruction pointer in __kretprobe_trampoline_handler x86/unwind/orc: Fixup kretprobe trampoline entry tracing: Remove kretprobe unknown indicator from stacktrace arch/arc/include/asm/ptrace.h |5 ++ arch/arc/kernel/kprobes.c |2 - arch/arm/probes/kprobes/core.c |3 - arch/arm64/kernel/probes/kprobes.c |3 - arch/csky/kernel/probes/kprobes.c |2 - arch/ia64/include/asm/ptrace.h |6 +++ arch/ia64/kernel/kprobes.c | 15 ++ arch/mips/kernel/kprobes.c |3 - arch/parisc/kernel/kprobes.c|4 +- arch/powerpc/kernel/kprobes.c | 13 - arch/riscv/kernel/probes/kprobes.c |2 - arch/s390/kernel/kprobes.c |2 - arch/sh/kernel/kprobes.c|2 - arch/sparc/kernel/kprobes.c |2 - arch/x86/include/asm/unwind.h |4 ++ arch/x86/include/asm/unwind_hints.h |5 ++ arch/x86/kernel/kprobes/core.c |5 +- arch/x86/kernel/unwind_orc.c| 16 +++ include/linux/kprobes.h | 41 +++-- kernel/kprobes.c| 84 +-- kernel/stacktrace.c | 22 + kernel/trace/trace_output.c | 27 ++- lib/error-inject.c |3 + 23 files changed, 170 insertions(+), 101 deletions(-) -- Masami Hiramatsu (Linaro)
Re: [PATCH V3 6/6] vDPA/ifcvf: verify mandatory feature bits for vDPA
On 3/12/2021 1:52 PM, Jason Wang wrote:
On 2021/3/11 3:19 下午, Zhu, Lingshan wrote:
On 3/11/2021 2:20 PM, Jason Wang wrote:
On 2021/3/11 12:16 下午, Zhu Lingshan wrote:
On 3/11/2021 11:20 AM, Jason Wang wrote:
On 2021/3/10 5:00 下午, Zhu Lingshan wrote:
vDPA requres VIRTIO_F_ACCESS_PLATFORM as a must, this commit
examines this when set features.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_base.c | 8
drivers/vdpa/ifcvf/ifcvf_base.h | 1 +
drivers/vdpa/ifcvf/ifcvf_main.c | 5 +
3 files changed, 14 insertions(+)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.c
b/drivers/vdpa/ifcvf/ifcvf_base.c
index ea6a78791c9b..58f47fdce385 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.c
+++ b/drivers/vdpa/ifcvf/ifcvf_base.c
@@ -224,6 +224,14 @@ u64 ifcvf_get_features(struct ifcvf_hw *hw)
return hw->hw_features;
}
+int ifcvf_verify_min_features(struct ifcvf_hw *hw)
+{
+ if (!(hw->hw_features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
+ return -EINVAL;
+
+ return 0;
+}
+
void ifcvf_read_net_config(struct ifcvf_hw *hw, u64 offset,
void *dst, int length)
{
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h
b/drivers/vdpa/ifcvf/ifcvf_base.h
index dbb8c10aa3b1..91c5735d4dc9 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -123,6 +123,7 @@ void io_write64_twopart(u64 val, u32 *lo, u32
*hi);
void ifcvf_reset(struct ifcvf_hw *hw);
u64 ifcvf_get_features(struct ifcvf_hw *hw);
u64 ifcvf_get_hw_features(struct ifcvf_hw *hw);
+int ifcvf_verify_min_features(struct ifcvf_hw *hw);
u16 ifcvf_get_vq_state(struct ifcvf_hw *hw, u16 qid);
int ifcvf_set_vq_state(struct ifcvf_hw *hw, u16 qid, u16 num);
struct ifcvf_adapter *vf_to_adapter(struct ifcvf_hw *hw);
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c
b/drivers/vdpa/ifcvf/ifcvf_main.c
index 25fb9dfe23f0..f624f202447d 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -179,6 +179,11 @@ static u64 ifcvf_vdpa_get_features(struct
vdpa_device *vdpa_dev)
static int ifcvf_vdpa_set_features(struct vdpa_device
*vdpa_dev, u64 features)
{
struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ int ret;
+
+ ret = ifcvf_verify_min_features(vf);
So this validate device features instead of driver which is the
one we really want to check?
Thanks
Hi Jason,
Here we check device feature bits to make sure the device support
ACCESS_PLATFORM.
If you want to check device features, you need to do that during
probe() and fail the probing if without the feature. But I think you
won't ship cards without ACCESS_PLATFORM.
Yes, there are no reasons ship a card without ACCESS_PLATFORM
In get_features(),
it will return a intersection of device features bit and driver
supported features bits(which includes ACCESS_PLATFORM).
Other components like QEMU should not set features bits more than
this intersection of bits. so we can make sure if this
ifcvf_verify_min_features() passed, both device and driver support
ACCESS_PLATFORM.
Are you suggesting check driver feature bits in
ifcvf_verify_min_features() in the meantime as well?
So it really depends on your hardware. If you hardware can always
offer ACCESS_PLATFORM, you just need to check driver features. This
is how vdpa_sim and mlx5_vdpa work.
Yes, we always support ACCESS_PLATFORM, so it is hard coded in the
macro IFCVF_SUPPORTED_FEATURES.
That's not what I read from the code:
features = ifcvf_get_features(vf) & IFCVF_SUPPORTED_FEATURES;
ifcvf_get_features() reads device feature bits(which should always has
ACCSSS_PLATFORM) and IFCVF_SUPPORTED_FEATURES is the driver supported
feature bits which hard coded ACCESS_PLATFORM, so the intersection
should include ACCESS_PLATFORM.
the intersection "features" is returned in get_features(), qemu should
set features according to it.
Now we check whether device support this feature bit as a double
conformation, are you suggesting we should check whether
ACCESS_PLATFORM & IFCVF_SUPPORTED_FEATURES
in set_features() as well?
If we know device will always offer ACCESS_PLATFORM, there's no need
to check it again. What we should check if whether driver set that,
and if it doesn't we need to fail set_features(). I think there's
little chance that IFCVF can work when IOMMU_PLATFORM is not negotiated.
Agree, will check the features bit to set instead of device feature
bits. Thanks!
I prefer check both device and IFCVF_SUPPORTED_FEATURES both, more
reliable.
So again, if you want to check device features, set_features() is not
the proper place. We need to fail the probe in this case.
Thanks
Thanks!
Thanks
Thanks！
+ if (ret)
+ return ret;
vf->req_features = features;
___
Virtualization mailing list
virtualizat...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [syzbot] KASAN: use-after-free Read in firmware_fallback_sysfs
syzbot has found a reproducer for the following issue on: HEAD commit:47142ed6 net: dsa: bcm_sf2: Qualify phydev->dev_flags base.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=11ccd12ad0 kernel config: https://syzkaller.appspot.com/x/.config?x=eec733599e95cd87 dashboard link: https://syzkaller.appspot.com/bug?extid=de271708674e2093097b syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15437d56d0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+de271708674e20930...@syzkaller.appspotmail.com platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 platform regulatory.0: Falling back to sysfs fallback for: regulatory.db == BUG: KASAN: use-after-free in __list_add_valid+0x81/0xa0 lib/list_debug.c:23 Read of size 8 at addr 888028830ac8 by task syz-executor.4/9852 CPU: 0 PID: 9852 Comm: syz-executor.4 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __list_add_valid+0x81/0xa0 lib/list_debug.c:23 __list_add include/linux/list.h:67 [inline] list_add include/linux/list.h:86 [inline] fw_load_sysfs_fallback drivers/base/firmware_loader/fallback.c:516 [inline] fw_load_from_user_helper drivers/base/firmware_loader/fallback.c:581 [inline] firmware_fallback_sysfs+0x455/0xe20 drivers/base/firmware_loader/fallback.c:657 _request_firmware+0xa80/0xe80 drivers/base/firmware_loader/main.c:831 request_firmware+0x32/0x50 drivers/base/firmware_loader/main.c:875 reg_reload_regdb+0x7a/0x240 net/wireless/reg.c:1095 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x465f69 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f6d26af9188 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0056bf60 RCX: 00465f69 RDX: RSI: 2240 RDI: 0003 RBP: 004bfa8f R08: R09: R10: R11: 0246 R12: 0056bf60 R13: 7ffdd4adb6bf R14: 7f6d26af9300 R15: 00022000 Allocated by task 9835: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:427 [inline] kasan_kmalloc mm/kasan/common.c:506 [inline] kasan_kmalloc mm/kasan/common.c:465 [inline] __kasan_kmalloc+0x99/0xc0 mm/kasan/common.c:515 kmalloc include/linux/slab.h:554 [inline] kzalloc include/linux/slab.h:684 [inline] __allocate_fw_priv drivers/base/firmware_loader/main.c:186 [inline] alloc_lookup_fw_priv drivers/base/firmware_loader/main.c:250 [inline] _request_firmware_prepare drivers/base/firmware_loader/main.c:744 [inline] _request_firmware+0x2de/0xe80 drivers/base/firmware_loader/main.c:806 request_firmware+0x32/0x50 drivers/base/firmware_loader/main.c:875 reg_reload_regdb+0x7a/0x240 net/wireless/reg.c:1095 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 9835:
Re: [PATCH v2 2/2] usb: typec: tcpci_maxim: configure charging & data paths
On 3/11/21 9:24 PM, Badhri Jagan Sridharan wrote:
> The change exposes the data_role and the orientation as a extcon
> interface for configuring the USB data controller.
>
> Signed-off-by: Badhri Jagan Sridharan
> ---
> Changes since V1:
> - Dropped changes related to get_/set_current_limit and pd_capable
> callback. Will send them in as separate patches.
> ---
> drivers/usb/typec/tcpm/tcpci_maxim.c | 56
> 1 file changed, 56 insertions(+)
>
> diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c
> b/drivers/usb/typec/tcpm/tcpci_maxim.c
> index 041a1c393594..1210445713ee 100644
> --- a/drivers/usb/typec/tcpm/tcpci_maxim.c
> +++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
> @@ -7,6 +7,8 @@
>
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -46,6 +48,8 @@ struct max_tcpci_chip {
> struct device *dev;
> struct i2c_client *client;
> struct tcpm_port *port;
> + bool attached;
> + struct extcon_dev *extcon;
> };
>
> static const struct regmap_range max_tcpci_tcpci_range[] = {
> @@ -439,6 +443,39 @@ static int tcpci_init(struct tcpci *tcpci, struct
> tcpci_data *data)
> return -1;
> }
>
> +static void max_tcpci_set_roles(struct tcpci *tcpci, struct tcpci_data
> *data, bool attached,
> + enum typec_role role, enum typec_data_role
> data_role)
> +{
> + struct max_tcpci_chip *chip = tdata_to_max_tcpci(data);
> +
> + chip->attached = attached;
> +
> + if (!attached) {
> + extcon_set_state_sync(chip->extcon, EXTCON_USB_HOST, 0);
> + extcon_set_state_sync(chip->extcon, EXTCON_USB, 0);
> + return;
> + }
> +
> + extcon_set_state_sync(chip->extcon, data_role == TYPEC_HOST ?
> EXTCON_USB_HOST : EXTCON_USB,
> + 1);
> +}
> +
> +static void max_tcpci_set_cc_polarity(struct tcpci *tcpci, struct tcpci_data
> *data,
> + enum typec_cc_polarity polarity)
> +{
> + struct max_tcpci_chip *chip = tdata_to_max_tcpci(data);
> +
> + extcon_set_property(chip->extcon, EXTCON_USB,
> EXTCON_PROP_USB_TYPEC_POLARITY,
> + (union extcon_property_value)(int)polarity);
> + extcon_set_property(chip->extcon, EXTCON_USB_HOST,
> EXTCON_PROP_USB_TYPEC_POLARITY,
> + (union extcon_property_value)(int)polarity);
> +}
> +
> +static const unsigned int usbpd_extcon[] = {
> + EXTCON_USB,
> + EXTCON_USB_HOST,
> +};
> +
> static int max_tcpci_probe(struct i2c_client *client, const struct
> i2c_device_id *i2c_id)
> {
> int ret;
> @@ -472,6 +509,8 @@ static int max_tcpci_probe(struct i2c_client *client,
> const struct i2c_device_id
> chip->data.auto_discharge_disconnect = true;
> chip->data.vbus_vsafe0v = true;
> chip->data.set_partner_usb_comm_capable =
> max_tcpci_set_partner_usb_comm_capable;
> + chip->data.set_roles = max_tcpci_set_roles;
> + chip->data.set_cc_polarity = max_tcpci_set_cc_polarity;
>
> max_tcpci_init_regs(chip);
> chip->tcpci = tcpci_register_port(chip->dev, >data);
> @@ -484,6 +523,23 @@ static int max_tcpci_probe(struct i2c_client *client,
> const struct i2c_device_id
> if (ret < 0)
> goto unreg_port;
>
> + chip->extcon = devm_extcon_dev_allocate(>dev, usbpd_extcon);
> + if (IS_ERR(chip->extcon)) {
> + dev_err(>dev, "Error allocating extcon: %ld\n",
> PTR_ERR(chip->extcon));
> + ret = PTR_ERR(chip->extcon);
> + goto unreg_port;
> + }
> +
> + ret = devm_extcon_dev_register(>dev, chip->extcon);
> + if (ret < 0) {
> + dev_err(>dev, "failed to register extcon device");
> + goto unreg_port;
> + }
Effectively this mandates extcon support to be able to use this driver/chip.
Does that make sense ? If this is indeed mandatory, how did it work so far ?
Also, what makes this code chip specific ?
Thanks,
Guenter
> +
> + extcon_set_property_capability(chip->extcon, EXTCON_USB,
> EXTCON_PROP_USB_TYPEC_POLARITY);
> + extcon_set_property_capability(chip->extcon, EXTCON_USB_HOST,
> +EXTCON_PROP_USB_TYPEC_POLARITY);
> +
> device_init_wakeup(chip->dev, true);
> return 0;
>
>
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Tomorrow's linux-next merge of the akpm-current tree will get a
conflict in:
Documentation/admin-guide/kernel-parameters.txt
between commit:
f6e5aedf470b ("riscv: Add support for memtest")
from the risc-v tree and commit:
6b8f5ba8661b ("mm,memory_hotplug: add kernel boot option to enable
memmap_on_memory")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/admin-guide/kernel-parameters.txt
index b816481dfaef,04b4e76be65b..
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@@ -2800,23 -2802,7 +2808,23 @@@
seconds. Use this parameter to check at some
other rate. 0 disables periodic checking.
+ memory_hotplug.memmap_on_memory
+ [KNL,X86,ARM] Boolean flag to enable this feature.
+ Format: {on | off (default)}
+ When enabled, memory to build the pages tables for the
+ memmap array describing the hot-added range will be
taken
+ from the range itself, so the memmap page tables will be
+ self-hosted.
+ Since only single memory device ranges are supported at
+ the moment, this option is disabled by default because
+ it might have an impact on workloads that needs large
+ contiguous memory chunks.
+ The state of the flag can be read in
+ /sys/module/memory_hotplug/parameters/memmap_on_memory.
+ Note that even when enabled, there are a few cases where
+ the feature is not effective.
+
- memtest=[KNL,X86,ARM,PPC] Enable memtest
+ memtest=[KNL,X86,ARM,PPC,RISCV] Enable memtest
Format:
default : 0
Specifies the number of memtest passes to be
pgp24YcASmleU.pgp
Description: OpenPGP digital signature
Re: [syzbot] WARNING in handle_mm_fault
On Fri, Mar 12, 2021 at 3:30 AM Andy Lutomirski wrote: > > Your warning is odd, but I see the bug. It's in KVM. Hi Andy, By "your" you mean "kernel", right? ;) > On Thu, Mar 11, 2021 at 4:37 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:05a59d79 Merge git://git.kernel.org:/pub/scm/linux/kernel/.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=16f493ead0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=750735fdbc630971 > > dashboard link: https://syzkaller.appspot.com/bug?extid=7d7013084f0a806f3786 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+7d7013084f0a806f3...@syzkaller.appspotmail.com > > > > [ cut here ] > > raw_local_irq_restore() called with IRQs enabled > > WARNING: CPU: 0 PID: 8412 at kernel/locking/irqflag-debug.c:10 > > warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > > Modules linked in: > > CPU: 0 PID: 8412 Comm: syz-fuzzer Not tainted 5.12.0-rc2-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > > The above makes sense, but WTH is the below: > > > Code: be ff cc cc cc cc cc cc cc cc cc cc cc 80 3d 11 d1 ad 04 00 74 01 c3 > > 48 c7 c7 20 79 6b 89 c6 05 00 d1 ad 04 01 e8 75 5b be ff <0f> 0b c3 48 39 > > 77 10 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 > > RSP: :c9000185fac8 EFLAGS: 00010282 > > RAX: RBX: 8880194268a0 RCX: > > RBP: 0200 R08: R09: > > R13: ed1003284d14 R14: 0001 R15: 8880b9c36000 > > FS: 00c2ec90() GS:8880b9c0() knlGS: > > Call Trace: > > handle_mm_fault+0x1bc/0x7e0 mm/memory.c:4549 > > Code: 48 8d 05 97 25 3e 00 48 89 44 24 08 e8 6d 54 ea ff 90 e8 07 a1 ed ff > > eb a5 cc cc cc cc cc 8b 44 24 10 48 8b 4c 24 08 89 41 24 cc cc cc cc > > cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 48 8b > > RAX: 47f6 RBX: 47f6 RCX: 00d6 > > RDX: 4c00 RSI: 00d6 RDI: 0181cad0 > > RBP: 00c000301890 R08: 47f5 R09: 0059c5a0 > > R10: 00c0004e2000 R11: 0020 R12: 00fa > > R13: 00aa R14: 0093f064 R15: 0038 > > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 0 PID: 8412 Comm: syz-fuzzer Not tainted 5.12.0-rc2-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Call Trace: > > Now we start reading here: > > > __dump_stack lib/dump_stack.c:79 [inline] > > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > > panic+0x306/0x73d kernel/panic.c:231 > > __warn.cold+0x35/0x44 kernel/panic.c:605 > > report_bug+0x1bd/0x210 lib/bug.c:195 > > handle_bug+0x3c/0x60 arch/x86/kernel/traps.c:239 > > exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:259 > > asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:575 > > RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > > Code: be ff cc cc cc cc cc cc cc cc cc cc cc 80 3d 11 d1 ad 04 00 74 01 c3 > > 48 c7 c7 20 79 6b 89 c6 05 00 d1 ad 04 01 e8 75 5b be ff <0f> 0b c3 48 39 > > 77 10 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 > > RSP: :c9000185fac8 EFLAGS: 00010282 > > RAX: RBX: 8880194268a0 RCX: > > RDX: 88802f7b2400 RSI: 815b4435 RDI: f5200030bf4b > > RBP: 0200 R08: R09: > > R10: 815ad19e R11: R12: 0003 > > R13: ed1003284d14 R14: 0001 R15: 8880b9c36000 > > kvm_wait arch/x86/kernel/kvm.c:860 [inline] > > and there's the bug: > > /* > * halt until it's our turn and kicked. Note that we do safe halt > * for irq enabled case to avoid hang when lock info is overwritten > * in irq spinlock slowpath and no spurious interrupt occur to save > us. > */ > if (arch_irqs_disabled_flags(flags)) > halt(); > else > safe_halt(); > > out: > local_irq_restore(flags); > } > > The safe_halt path is bogus. It should just return instead of > restoring the IRQ flags. I think this should be fixed already by: https://patchwork.kernel.org/project/kvm/patch/1614057902-23774-1-git-send-email-wanpen...@tencent.com/ #syz fix: x86/kvm: Fix broken irq restoration in kvm_wait
[PATCH 0/1] Mediatek pinctrl patch
This series includes 1 patches: 1.add lock in mtk_rmw function. Zhiyong Tao (1): pinctrl: add lock in mtk_rmw function. drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 ++ drivers/pinctrl/mediatek/pinctrl-paris.c | 2 ++ 3 files changed, 8 insertions(+) -- 2.25.1
[PATCH] pinctrl: add lock in mtk_rmw function.
When multiple threads operate on the same register resource
which include multiple pin, It will make the register resource
wrong to control. So we add lock to avoid the case.
Signed-off-by: Zhiyong Tao
---
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 ++
drivers/pinctrl/mediatek/pinctrl-paris.c | 2 ++
3 files changed, 8 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 72f17f26acd8..fcf7c34a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -58,10 +58,14 @@ void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32
mask, u32 set)
{
u32 val;
+ mutex_lock(>lock);
+
val = mtk_r32(pctl, i, reg);
val &= ~mask;
val |= set;
mtk_w32(pctl, i, reg, val);
+
+ mutex_unlock(>lock);
}
static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index e2aae285b5fc..65eac708a3b3 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -251,6 +251,8 @@ struct mtk_pinctrl {
struct mtk_eint *eint;
struct mtk_pinctrl_group*groups;
const char **grp_names;
+ /* lock pin's register resource to avoid multiple threads issue*/
+ struct mutex lock;
};
void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index da1f19288aa6..48e823f6d293 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -970,6 +970,8 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev,
hw->nbase = hw->soc->nbase_names;
+ mutex_init(>lock);
+
err = mtk_pctrl_build_state(pdev);
if (err) {
dev_err(>dev, "build state failed: %d\n", err);
--
2.18.0
Re: [PATCH 2/2] vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails
On 2021/3/11 9:52 下午, Stefano Garzarella wrote:
In vhost_vdpa_set_config_call() if eventfd_ctx_fdget() fails the
'v->config_ctx' contains an error instead of a valid pointer.
Since we consider 'v->config_ctx' valid if it is not NULL, we should
set it to NULL in this case to avoid to use an invalid pointer in
other functions such as vhost_vdpa_config_put().
Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
Cc: lingshan@intel.com
Cc: sta...@vger.kernel.org
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
drivers/vhost/vdpa.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 00796e4ecfdf..f9ecdce5468a 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -331,8 +331,12 @@ static long vhost_vdpa_set_config_call(struct vhost_vdpa
*v, u32 __user *argp)
if (!IS_ERR_OR_NULL(ctx))
eventfd_ctx_put(ctx);
- if (IS_ERR(v->config_ctx))
- return PTR_ERR(v->config_ctx);
+ if (IS_ERR(v->config_ctx)) {
+ long ret = PTR_ERR(v->config_ctx);
+
+ v->config_ctx = NULL;
+ return ret;
+ }
v->vdpa->config->set_config_cb(v->vdpa, );
Re: [PATCH v2 1/2] usb: typec: tcpci: Add tcpc chip level callbacks
On Fri, Mar 12, 2021 at 07:33:45AM +0100, Greg Kroah-Hartman wrote: > On Thu, Mar 11, 2021 at 09:24:42PM -0800, Badhri Jagan Sridharan wrote: > > This change adds chip callbacks for the following operations: > > 1. Notifying port role > > 2. Notifying orientation > > This should be 2 different patches, one per callback, right? > > And where is the code using these callbacks? We can't add any hooks > without in-tree users, as you know. Ah, your second patch added that, sorry, missed it. This should be a 4 patch series, remember, only do one thing per patch. thanks, greg k-h
Re: [PATCH 1/2] vhost-vdpa: fix use-after-free of v->config_ctx
On 2021/3/11 9:52 下午, Stefano Garzarella wrote:
When the 'v->config_ctx' eventfd_ctx reference is released we didn't
set it to NULL. So if the same character device (e.g. /dev/vhost-vdpa-0)
is re-opened, the 'v->config_ctx' is invalid and calling again
vhost_vdpa_config_put() causes use-after-free issues like the
following refcount_t underflow:
refcount_t: underflow; use-after-free.
WARNING: CPU: 2 PID: 872 at lib/refcount.c:28
refcount_warn_saturate+0xae/0xf0
RIP: 0010:refcount_warn_saturate+0xae/0xf0
Call Trace:
eventfd_ctx_put+0x5b/0x70
vhost_vdpa_release+0xcd/0x150 [vhost_vdpa]
__fput+0x8e/0x240
fput+0xe/0x10
task_work_run+0x66/0xa0
exit_to_user_mode_prepare+0x118/0x120
syscall_exit_to_user_mode+0x21/0x50
? __x64_sys_close+0x12/0x40
do_syscall_64+0x45/0x50
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
Cc: lingshan@intel.com
Cc: sta...@vger.kernel.org
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
drivers/vhost/vdpa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index ef688c8c0e0e..00796e4ecfdf 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -308,8 +308,10 @@ static long vhost_vdpa_get_vring_num(struct vhost_vdpa *v,
u16 __user *argp)
static void vhost_vdpa_config_put(struct vhost_vdpa *v)
{
- if (v->config_ctx)
+ if (v->config_ctx) {
eventfd_ctx_put(v->config_ctx);
+ v->config_ctx = NULL;
+ }
}
static long vhost_vdpa_set_config_call(struct vhost_vdpa *v, u32 __user *argp)
Re: [PATCH v4 13/34] KVM: arm64: Enable access to sanitized CPU features at EL2
On Thursday 11 Mar 2021 at 19:36:39 (+), Will Deacon wrote:
> On Wed, Mar 10, 2021 at 05:57:30PM +, Quentin Perret wrote:
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 066030717a4c..f2d8b479ff74 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -1154,6 +1154,18 @@ u64 read_sanitised_ftr_reg(u32 id)
> > }
> > EXPORT_SYMBOL_GPL(read_sanitised_ftr_reg);
> >
> > +int copy_ftr_reg(u32 id, struct arm64_ftr_reg *dst)
> > +{
> > + struct arm64_ftr_reg *regp = get_arm64_ftr_reg(id);
> > +
> > + if (!regp)
> > + return -EINVAL;
> > +
> > + memcpy(dst, regp, sizeof(*regp));
>
> Can you not just use struct assignment here?
Sure.
> > diff --git a/arch/arm64/kvm/hyp/nvhe/cache.S
> > b/arch/arm64/kvm/hyp/nvhe/cache.S
> > new file mode 100644
> > index ..36cef6915428
> > --- /dev/null
> > +++ b/arch/arm64/kvm/hyp/nvhe/cache.S
> > @@ -0,0 +1,13 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Code copied from arch/arm64/mm/cache.S.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +SYM_FUNC_START_PI(__flush_dcache_area)
> > + dcache_by_line_op civac, sy, x0, x1, x2, x3
> > + ret
> > +SYM_FUNC_END_PI(__flush_dcache_area)
>
> Separate patch for this? (or fold it into that one really near the start
> that introduces some other PI helpers).
Right, I guess that'll make reverts and such easier so why not.
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 4f2f1e3145de..84be93df52fa 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -2775,3 +2776,23 @@ void kvm_sys_reg_table_init(void)
> > /* Clear all higher bits. */
> > cache_levels &= (1 << (i*3))-1;
> > }
> > +
> > +#undef KVM_HYP_CPU_FTR_REG
> > +#define KVM_HYP_CPU_FTR_REG(id, name) \
> > + { .sys_id = id, .dst = (struct arm64_ftr_reg *)_nvhe_sym(name) },
> > +struct __ftr_reg_copy_entry {
> > + u32 sys_id;
> > + struct arm64_ftr_reg*dst;
> > +} hyp_ftr_regs[] __initdata = {
> > + #include
> > +};
>
> This looks a bit elaborate to me. Why can't you just spell things out here
> like:
>
> #define KVM_HYP_CPU_FTR_REG(id, name) \
> { .sys_id = id, .dst = (struct arm64_ftr_reg *)_nvhe_sym(name) }
>
> struct __ftr_reg_copy_entry {
> u32 sys_id;
> struct arm64_ftr_reg*dst;
> } hyp_ftr_regs[] __initdata = {
> KVM_HYP_CPU_FTR_REG(SYS_CTR_EL0, arm64_ftr_reg_ctrel0),
> ...
> };
>
> and then have the header file be a normal, guarded header which just
> declares these things? The id parameter to the macro isn't used there.
I just tried to reduce the boilerplate as much as possible -- in the
current form you only need to add additional features to the header
it'll 'just work'.
Thanks,
Quentin
Re: [PATCH v2 1/2] usb: typec: tcpci: Add tcpc chip level callbacks
On Thu, Mar 11, 2021 at 09:24:42PM -0800, Badhri Jagan Sridharan wrote: > This change adds chip callbacks for the following operations: > 1. Notifying port role > 2. Notifying orientation This should be 2 different patches, one per callback, right? And where is the code using these callbacks? We can't add any hooks without in-tree users, as you know. thanks, greg k-h
Re: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master hnaz-linux-mm/master v5.12-rc2
next-20210311]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/qiang-zhang-windriver-com/ARM-Fix-incorrect-use-of-smp_processor_id-by-syzbot-report/20210312-121529
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
a74e6a014c9d4d4161061f770c9b4f98372ac778
config: arm-pxa168_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/b31b47976c6f81426cc00c99cc1452a60e89d972
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
qiang-zhang-windriver-com/ARM-Fix-incorrect-use-of-smp_processor_id-by-syzbot-report/20210312-121529
git checkout b31b47976c6f81426cc00c99cc1452a60e89d972
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from arch/arm/mm/fault.c:21:
arch/arm/include/asm/system_misc.h: In function 'harden_branch_predictor':
>> arch/arm/include/asm/system_misc.h:25:2: warning: ISO C90 forbids mixed
>> declarations and code [-Wdeclaration-after-statement]
25 | harden_branch_predictor_fn_t fn =
per_cpu(harden_branch_predictor_fn,
| ^~~~
arch/arm/mm/fault.c: At top level:
arch/arm/mm/fault.c:518:1: warning: no previous prototype for 'do_DataAbort'
[-Wmissing-prototypes]
518 | do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs
*regs)
| ^~~~
arch/arm/mm/fault.c:548:1: warning: no previous prototype for
'do_PrefetchAbort' [-Wmissing-prototypes]
548 | do_PrefetchAbort(unsigned long addr, unsigned int ifsr, struct
pt_regs *regs)
| ^~~~
--
In file included from arch/arm/mm/proc-v7-bugs.c:9:
arch/arm/include/asm/system_misc.h: In function 'harden_branch_predictor':
>> arch/arm/include/asm/system_misc.h:25:2: warning: ISO C90 forbids mixed
>> declarations and code [-Wdeclaration-after-statement]
25 | harden_branch_predictor_fn_t fn =
per_cpu(harden_branch_predictor_fn,
| ^~~~
arch/arm/mm/proc-v7-bugs.c: At top level:
arch/arm/mm/proc-v7-bugs.c:142:6: warning: no previous prototype for
'cpu_v7_ca8_ibe' [-Wmissing-prototypes]
142 | void cpu_v7_ca8_ibe(void)
| ^~
arch/arm/mm/proc-v7-bugs.c:148:6: warning: no previous prototype for
'cpu_v7_ca15_ibe' [-Wmissing-prototypes]
148 | void cpu_v7_ca15_ibe(void)
| ^~~
arch/arm/mm/proc-v7-bugs.c:154:6: warning: no previous prototype for
'cpu_v7_bugs_init' [-Wmissing-prototypes]
154 | void cpu_v7_bugs_init(void)
| ^~~~
vim +25 arch/arm/include/asm/system_misc.h
9f97da78bf0182 David Howells 2012-03-28 18
f5fe12b1eaee22 Russell King 2018-05-14 19 #ifdef
CONFIG_HARDEN_BRANCH_PREDICTOR
f5fe12b1eaee22 Russell King 2018-05-14 20 typedef void
(*harden_branch_predictor_fn_t)(void);
f5fe12b1eaee22 Russell King 2018-05-14 21
DECLARE_PER_CPU(harden_branch_predictor_fn_t, harden_branch_predictor_fn);
f5fe12b1eaee22 Russell King 2018-05-14 22 static inline void
harden_branch_predictor(void)
f5fe12b1eaee22 Russell King 2018-05-14 23 {
b31b47976c6f81 Zqiang2021-03-12 24 preempt_disable();
f5fe12b1eaee22 Russell King 2018-05-14 @25 harden_branch_predictor_fn_t fn
= per_cpu(harden_branch_predictor_fn,
f5fe12b1eaee22 Russell King 2018-05-14 26
smp_processor_id());
b31b47976c6f81 Zqiang2021-03-12 27 preempt_enable();
f5fe12b1eaee22 Russell King 2018-05-14 28 if (fn)
f5fe12b1eaee22 Russell King 2018-05-14 29 fn();
f5fe12b1eaee22 Russell King 2018-05-14 30 }
f5fe12b1eaee22 Russell King 2018-05-14 31 #else
f5fe12b1eaee22 Russell King 2018-05-14 32 #define harden_branch_predictor()
do { } while (0)
f5fe12b1eaee22 Russell King 2018-05-14 33 #endif
f5fe12b1eaee22 Russell King 2018-05-14 34
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] ARM: Fix incorrect use of smp_processor_id() by syzbot report
On Fri, Mar 12, 2021 at 5:13 AM wrote:
>
> From: Zqiang
>
> BUG: using smp_processor_id() in preemptible [] code:
> syz-executor.0/15841
> caller is debug_smp_processor_id+0x20/0x24
> lib/smp_processor_id.c:64
>
> The smp_processor_id() is used in a code segment when
> preemption has been disabled, otherwise, when preemption
> is enabled this pointer is usually no longer useful
> since it may no longer point to per cpu data of the
> current processor.
>
> Reported-by: syzbot
> Fixes: f5fe12b1eaee ("ARM: spectre-v2: harden user aborts in kernel space")
> Signed-off-by: Zqiang
> ---
> arch/arm/include/asm/system_misc.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/include/asm/system_misc.h
> b/arch/arm/include/asm/system_misc.h
> index 66f6a3ae68d2..61916dc7d361 100644
> --- a/arch/arm/include/asm/system_misc.h
> +++ b/arch/arm/include/asm/system_misc.h
> @@ -21,8 +21,10 @@ typedef void (*harden_branch_predictor_fn_t)(void);
> DECLARE_PER_CPU(harden_branch_predictor_fn_t, harden_branch_predictor_fn);
> static inline void harden_branch_predictor(void)
> {
> + preempt_disable();
> harden_branch_predictor_fn_t fn = per_cpu(harden_branch_predictor_fn,
> smp_processor_id());
> + preempt_enable();
> if (fn)
> fn();
> }
Hi Qiang,
If the CPU can change here, what if it changes right after preempt_enable()?
Disabling preemption just around reading the callback looks like a
no-op. Shouldn't we disable preemption at least around reading and
calling the callback?
On the second look, the fn seems to be const after init, so maybe we
need to use raw_smp_processor_id() instead with an explanatory
comment?
Re: [mm/highmem] 61b205f579: WARNING:at_mm/highmem.c:#__kmap_local_sched_out
Hi Ira,
On Thu, Mar 11, 2021 at 08:02:20AM -0800, Ira Weiny wrote:
> On Tue, Mar 09, 2021 at 08:53:04PM +, Chaitanya Kulkarni wrote:
> > Ira,
> >
> > On 3/4/21 00:23, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed the following commit (built with gcc-9):
> > >
> > > commit: 61b205f579911a11f0b576f73275eca2aed0d108 ("mm/highmem: Convert
> > > memcpy_[to|from]_page() to kmap_local_page()")
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > >
> > >
> > > in testcase: trinity
> > > version: trinity-static-i386-x86_64-f93256fb_2019-08-28
> > > with following parameters:
> > >
> > > runtime: 300s
> > >
> > > test-description: Trinity is a linux system call fuzz tester.
> > > test-url: http://codemonkey.org.uk/projects/trinity/
> > >
> > >
> > > on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m
> > > 8G
> > >
> > > caused below changes (please refer to attached dmesg/kmsg for entire
> > > log/backtrace):
> >
> > Is the fix for this been posted yet ?
>
> No. I've been unable to reproduce it yet.
just FYI
the issue does not always happen but the rate on 61b205f579 is not low,
while we didn't observe it happen on parent commit.
bb90d4bc7b6a536b 61b205f579911a11f0b576f7327
---
fail:runs %reproductionfail:runs
| | |
:38 16% 6:38dmesg.EIP:__kmap_local_sched_in
:38 16% 6:38dmesg.EIP:__kmap_local_sched_out
:38 16% 6:38
dmesg.WARNING:at_mm/highmem.c:#__kmap_local_sched_in
:38 16% 6:38
dmesg.WARNING:at_mm/highmem.c:#__kmap_local_sched_out
also please permit me to quote our internal analysis by Zhengjun (cced)
(Thanks a lot, Zhengjun)
"the commit has the potential to cause the issue.
It replaces " kmap_atomic" to " kmap_local_page".
Most of the two API is the same, except for " kmap_atomic" disable preemption
and cannot sleep.
I check the issue happened when there is a preemption, in FBC "
kmap_local_page",
the preemption is enabled, the issue may happen."
"
>
> Ira
>
> >
> > (asking since I didn't see the fix and my mailer is dropping emails from
> > lkml).
Re: [PATCH] tools/power/x86/turbostat: Fix TCC offset bit mask
Hi Len, thank you for your reply. On Thu, Mar 11, 2021 at 3:19 PM Len Brown wrote: > > Thanks for the close read, Doug. > > This field size actually varies from system to system, > but the reality is that the offset is never that big, and so the > smaller mask is sufficient. Disagree. I want to use an offset of 26. > Finally, this may all be moot, because there is discussion that using > the offset this way is simply erroneous. Disagree. It works great. As far as I know/recall I was the only person that responded to Rui's thread "thermal/intel: introduce tcc cooling driver" [1] And, I spent quite a bit of time doing so. However, I agree the response seems different between the two systems under test, Rui's and mine. [1] https://marc.info/?l=linux-pm=161070345329806=2 > stay tuned. O.K. ... Doug > > -Len > > > On Sat, Jan 16, 2021 at 12:07 PM Doug Smythies > wrote: > > > > The TCC offset mask is incorrect, resulting in > > incorrect target temperature calculations, if > > the offset is big enough to exceed the mask size. > > > > Signed-off-by: Doug Smythies > > --- > > tools/power/x86/turbostat/turbostat.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tools/power/x86/turbostat/turbostat.c > > b/tools/power/x86/turbostat/turbostat.c > > index 389ea5209a83..d7acdd4d16c4 100644 > > --- a/tools/power/x86/turbostat/turbostat.c > > +++ b/tools/power/x86/turbostat/turbostat.c > > @@ -4823,7 +4823,7 @@ int read_tcc_activation_temp() > > > > target_c = (msr >> 16) & 0xFF; > > > > - offset_c = (msr >> 24) & 0xF; > > + offset_c = (msr >> 24) & 0x3F; > > > > tcc = target_c - offset_c; > > > > -- > > 2.25.1 > > > > > -- > Len Brown, Intel Open Source Technology Center
[PATCH v2 8/8] pinctrl: stm32: Add STM32H750 MCU pinctrl support
From: dillon min
This patch adds STM32H750 pinctrl and GPIO support
since stm32h750 has the same pin alternate functions
with stm32h743, so just reuse the stm32h743's pinctrl
driver
Signed-off-by: dillon min
---
v2:
- add compatible string st,stm32h750-pinctrl to pinctl-stm32h743.c as they
have same pin alternate functions
- add STM32H750 to Kconfig description
drivers/pinctrl/stm32/Kconfig | 2 +-
drivers/pinctrl/stm32/pinctrl-stm32h743.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
index f36f29113370..fb1ffc94c57f 100644
--- a/drivers/pinctrl/stm32/Kconfig
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -35,7 +35,7 @@ config PINCTRL_STM32F769
select PINCTRL_STM32
config PINCTRL_STM32H743
- bool "STMicroelectronics STM32H743 pin control" if COMPILE_TEST &&
!MACH_STM32H743
+ bool "STMicroelectronics STM32H743/STM32H750 pin control" if
COMPILE_TEST && !MACH_STM32H743
depends on OF && HAS_IOMEM
default MACH_STM32H743
select PINCTRL_STM32
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32h743.c
b/drivers/pinctrl/stm32/pinctrl-stm32h743.c
index ffe7b5271506..700206c7bc11 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32h743.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32h743.c
@@ -1966,6 +1966,9 @@ static const struct of_device_id stm32h743_pctrl_match[]
= {
.compatible = "st,stm32h743-pinctrl",
.data = _match_data,
},
+ { .compatible = "st,stm32h750-pinctrl",
+ .data = _match_data,
+ },
{ }
};
--
2.7.4
[PATCH v2 6/8] ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6
From: dillon min
This patchset has following changes:
- introduce stm32h750.dtsi to support stm32h750 value line
- add stm32h750i-art-pi.dtb (arch/arm/boot/dts/Makefile)
- add dts binding usart3 for bt, uart4 for console
usart3/uart4 pinctrl in stm32h7-pinctrl.dtsi
usart3/uart4 register in stm32h743.dtsi
- add dts binding sdmmc2 for wifi
sdmmc2 pinctrl in stm32h7-pinctrl.dtsi
sdmmc2 register in stm32h743.dtsi
- add spi1 pinctrl in stm32h7-pinctrl.dtsi for spi flash
- add stm32h750-art-pi.dts to support art-pi board
art-pi board component:
- 8MiB qspi flash
- 16MiB spi flash
- 32MiB sdram
- ap6212 wifi
the detail board information can be found at:
https://art-pi.gitee.io/website/
Signed-off-by: dillon min
---
v2:
- fix author name/copyright mistake
- make item in stm32h750i-art-pi.dts sort by letter
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/stm32h7-pinctrl.dtsi | 87
arch/arm/boot/dts/stm32h743.dtsi| 30 +
arch/arm/boot/dts/stm32h750.dtsi| 5 +
arch/arm/boot/dts/stm32h750i-art-pi.dts | 228
5 files changed, 351 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32h750.dtsi
create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e..a19c5ab9df84 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1071,6 +1071,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32746g-eval.dtb \
stm32h743i-eval.dtb \
stm32h743i-disco.dtb \
+ stm32h750i-art-pi.dtb \
stm32mp153c-dhcom-drc02.dtb \
stm32mp157a-avenger96.dtb \
stm32mp157a-dhcor-avenger96.dtb \
diff --git a/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
b/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
index 9fcc1e3ba925..0d08225a16de 100644
--- a/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
@@ -231,6 +231,50 @@
};
};
+ sdmmc2_b4_pins_a: sdmmc2-b4-0 {
+ pins {
+ pinmux = ,
/* SDMMC1_D0 */
+,
/* SDMMC1_D1 */
+,
/* SDMMC1_D2 */
+,
/* SDMMC1_D3 */
+,
/* SDMMC1_CK */
+;
/* SDMMC1_CMD */
+ slew-rate = <3>;
+ drive-push-pull;
+ bias-disable;
+ };
+ };
+
+ sdmmc2_b4_od_pins_a: sdmmc2-b4-od-0 {
+ pins1 {
+ pinmux = ,
/* SDMMC2_D0 */
+,
/* SDMMC1_D1 */
+,
/* SDMMC1_D2 */
+,
/* SDMMC1_D3 */
+;
/* SDMMC1_CK */
+ slew-rate = <3>;
+ drive-push-pull;
+ bias-disable;
+ };
+ pins2{
+ pinmux = ;
/* SDMMC1_CMD */
+ slew-rate = <3>;
+ drive-open-drain;
+ bias-disable;
+ };
+ };
+
+ sdmmc2_b4_sleep_pins_a: sdmmc2-b4-sleep-0 {
+ pins {
+ pinmux = , /* SDMMC1_D0 */
+, /* SDMMC1_D1 */
+, /* SDMMC1_D2 */
+, /* SDMMC1_D3 */
+, /* SDMMC1_CK */
+; /* SDMMC1_CMD */
+ };
+ };
+
sdmmc1_dir_pins_a: sdmmc1-dir-0 {
pins1 {
pinmux = ,
/* SDMMC1_D0DIR */
@@ -281,6 +325,32 @@
};
};
+ usart3_pins: usart3-0 {
+ pins1 {
+ pinmux = ;
/* USART3_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+
[PATCH v2 7/8] ARM: stm32: Add a new SOC - STM32H750
From: dillon min
The STM32H750 is a Cortex-M7 MCU running at 480MHz and containing 128KBytes
internal flash, 1MiB SRAM.
Signed-off-by: dillon min
---
v2: no changes
arch/arm/mach-stm32/board-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-dt.c
index 011d57b488c2..a766310d8dca 100644
--- a/arch/arm/mach-stm32/board-dt.c
+++ b/arch/arm/mach-stm32/board-dt.c
@@ -17,6 +17,7 @@ static const char *const stm32_compat[] __initconst = {
"st,stm32f746",
"st,stm32f769",
"st,stm32h743",
+ "st,stm32h750",
"st,stm32mp157",
NULL
};
--
2.7.4
[PATCH v2 5/8] ARM: dts: stm32: add stm32h750-pinctrl.dtsi
From: dillon min
This patch add stm32h750-pinctrl.dtsi which just
reference stm32h7-pinctrl.dtsi
Signed-off-by: dillon min
---
v2: no changes
arch/arm/boot/dts/stm32h750-pinctrl.dtsi | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32h750-pinctrl.dtsi
diff --git a/arch/arm/boot/dts/stm32h750-pinctrl.dtsi
b/arch/arm/boot/dts/stm32h750-pinctrl.dtsi
new file mode 100644
index ..24e99970167c
--- /dev/null
+++ b/arch/arm/boot/dts/stm32h750-pinctrl.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) STMicroelectronics 2021 - All Rights Reserved
+ * Author: Dillon Min for STMicroelectronics.
+ */
+
+#include "stm32h7-pinctrl.dtsi"
+
+{
+ compatible = "st,stm32h750-pinctrl";
+};
--
2.7.4
[PATCH v2 4/8] ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750
From: dillon min
This patch is intend to add support stm32h750 value line,
just add stm32h7-pinctrl.dtsi for extending, with following changes:
- rename stm32h743-pinctrl.dtsi to stm32h7-pinctrl.dtsi
- move compatible string "st,stm32h743-pinctrl" from stm32h7-pinctrl.dtsi
to stm32h743-pinctrl.dtsi
Signed-off-by: dillon min
---
v2:
- reorganize the pinctrl device tree about stm32h7-pinctrl/stm32h743/750-pinctrl
stm32h7-pinctrl.dtsi --> stm32h743-pinctrl.dtsi --> stm32h743i-disco.dts
| |-> stm32h743i-eval.dts
|-> stm32h750-pinctrl.dtsi --> stm32h750i-art-pi.dts
same to the stm32f7/f4's pinctrl style
arch/arm/boot/dts/stm32h7-pinctrl.dtsi | 305 ++
arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 307 +--
2 files changed, 311 insertions(+), 301 deletions(-)
create mode 100644 arch/arm/boot/dts/stm32h7-pinctrl.dtsi
diff --git a/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
b/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
new file mode 100644
index ..9fcc1e3ba925
--- /dev/null
+++ b/arch/arm/boot/dts/stm32h7-pinctrl.dtsi
@@ -0,0 +1,305 @@
+/*
+ * Copyright 2017 - Alexandre Torgue
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+
+/ {
+ soc {
+ pinctrl: pin-controller {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x5802 0x3000>;
+ interrupt-parent = <>;
+ st,syscfg = < 0x8>;
+ pins-are-numbered;
+
+ gpioa: gpio@5802 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x0 0x400>;
+ clocks = < GPIOA_CK>;
+ st,bank-name = "GPIOA";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpiob: gpio@58020400 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x400 0x400>;
+ clocks = < GPIOB_CK>;
+ st,bank-name = "GPIOB";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpioc: gpio@58020800 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x800 0x400>;
+ clocks = < GPIOC_CK>;
+ st,bank-name = "GPIOC";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpiod: gpio@58020c00 {
+
[PATCH v2 3/8] dt-bindings: pinctrl: stm32: Add stm32h750 pinctrl
From: dillon min This patch intend to add pinctrl configuration support for stm32h750 value line The datasheet of stm32h750 value line can be found at: https://www.st.com/resource/en/datasheet/stm32h750ib.pdf Signed-off-by: dillon min --- v2: just add more commit message description Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 72877544ca78..59f33cbe8f48 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -24,6 +24,7 @@ properties: - st,stm32f746-pinctrl - st,stm32f769-pinctrl - st,stm32h743-pinctrl + - st,stm32h750-pinctrl - st,stm32mp157-pinctrl - st,stm32mp157-z-pinctrl -- 2.7.4
[PATCH v2 2/8] dt-bindings: arm: stm32: Add compatible strings for ART-PI board
From: dillon min Art-pi based on stm32h750xbh6, with following resources: -8MiB QSPI flash -16MiB SPI flash -32MiB SDRAM -AP6212 wifi, bt, fm detail information can be found at: https://art-pi.gitee.io/website/ Signed-off-by: dillon min --- v2: no changes Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index e7525a3395e5..306e7551ad39 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -53,6 +53,10 @@ properties: - const: st,stm32h743 - items: - enum: + - st,stm32h750i-art-pi + - const: st,stm32h750 + - items: + - enum: - shiratech,stm32mp157a-iot-box # IoT Box - shiratech,stm32mp157a-stinger96 # Stinger96 - st,stm32mp157c-ed1 -- 2.7.4
[PATCH v2 1/8] Documentation: arm: stm32: Add stm32h750 value line doc
From: dillon min This patchset add support for soc stm32h750, stm32h750 has mirror different from stm32h743 itemstm32h743 stm32h750 flash size: 2MiB 128KiB adc:none 3 crypto-hash:none aes/hamc/des/tdes/md5/sha detail information can be found at: https://www.st.com/en/microcontrollers-microprocessors/stm32h750-value-line.html Signed-off-by: dillon min --- v2: just add more commit message description Documentation/arm/index.rst| 1 + Documentation/arm/stm32/stm32h750-overview.rst | 33 ++ 2 files changed, 34 insertions(+) create mode 100644 Documentation/arm/stm32/stm32h750-overview.rst diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst index b4bea32472b6..d4f34ae9e6f4 100644 --- a/Documentation/arm/index.rst +++ b/Documentation/arm/index.rst @@ -52,6 +52,7 @@ SoC-specific documents stm32/stm32f746-overview stm32/overview stm32/stm32h743-overview + stm32/stm32h750-overview stm32/stm32f769-overview stm32/stm32f429-overview stm32/stm32mp157-overview diff --git a/Documentation/arm/stm32/stm32h750-overview.rst b/Documentation/arm/stm32/stm32h750-overview.rst new file mode 100644 index ..c8ce59ec3bd1 --- /dev/null +++ b/Documentation/arm/stm32/stm32h750-overview.rst @@ -0,0 +1,33 @@ +== +STM32H750 Overview +== + +Introduction + + +The STM32H750 is a Cortex-M7 MCU aimed at various applications. +It features: + +- Cortex-M7 core running up to @480MHz +- 128K internal flash, 1MBytes internal RAM +- FMC controller to connect SDRAM, NOR and NAND memories +- Dual mode QSPI +- SD/MMC/SDIO support +- Ethernet controller +- USB OTFG FS & HS controllers +- I2C, SPI, CAN busses support +- Several 16 & 32 bits general purpose timers +- Serial Audio interface +- LCD controller +- HDMI-CEC +- SPDIFRX +- DFSDM + +Resources +- + +Datasheet and reference manual are publicly available on ST website (STM32H750_). + +.. _STM32H750: https://www.st.com/en/microcontrollers-microprocessors/stm32h750-value-line.html + +:Authors: Dillon Min -- 2.7.4
[PATCH v2 0/8] ARM: STM32: add art-pi(stm32h750xbh6) board support
From: dillon min This patchset intend to add art-pi board support, this board developed by rt-thread(https://www.rt-thread.org/). Board resources: 8MiB QSPI flash 16MiB SPI flash 32MiB SDRAM AP6212 wifi,bt,fm comb sw context: - as stm32h750 just has 128k bytes internal flash, so running a fw on internal flash to download u-boot/kernel to qspi flash, boot u-boot/kernel from qspi flash. this fw is based on rt-thread. - kernel can be xip on qspi flash or load to sdram - root filesystem is jffs2(created by buildroot), stored on spi flash to support the boad, add following changes. - fix r0-r3, r12 register restore failed after svc call, - add dts binding - update yaml doc changes in v2: - reorganize the pinctrl device tree about stm32h7-pinctrl/stm32h743/750-pinctrl stm32h7-pinctrl.dtsi --> stm32h743-pinctrl.dtsi --> stm32h743i-disco.dts | |-> stm32h743i-eval.dts |-> stm32h750-pinctrl.dtsi --> stm32h750i-art-pi.dts same to the stm32f7/f4's pinctrl style - fix author name/copyright mistake - add compatible string st,stm32h750-pinctrl to pinctl-stm32h743.c as they have same pin alternate functions, update Kconfig description - make item in stm32h750i-art-pi.dts sort by letter dillon min (8): Documentation: arm: stm32: Add stm32h750 value line doc dt-bindings: arm: stm32: Add compatible strings for ART-PI board dt-bindings: pinctrl: stm32: Add stm32h750 pinctrl ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750 ARM: dts: stm32: add stm32h750-pinctrl.dtsi ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6 ARM: stm32: Add a new SOC - STM32H750 pinctrl: stm32: Add STM32H750 MCU pinctrl support Documentation/arm/index.rst| 1 + Documentation/arm/stm32/stm32h750-overview.rst | 33 ++ .../devicetree/bindings/arm/stm32/stm32.yaml | 4 + .../bindings/pinctrl/st,stm32-pinctrl.yaml | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/stm32h7-pinctrl.dtsi | 392 + arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 307 +--- arch/arm/boot/dts/stm32h743.dtsi | 30 ++ arch/arm/boot/dts/stm32h750-pinctrl.dtsi | 11 + arch/arm/boot/dts/stm32h750.dtsi | 5 + arch/arm/boot/dts/stm32h750i-art-pi.dts| 228 arch/arm/mach-stm32/board-dt.c | 1 + drivers/pinctrl/stm32/Kconfig | 2 +- drivers/pinctrl/stm32/pinctrl-stm32h743.c | 3 + 14 files changed, 717 insertions(+), 302 deletions(-) create mode 100644 Documentation/arm/stm32/stm32h750-overview.rst create mode 100644 arch/arm/boot/dts/stm32h7-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/stm32h750-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/stm32h750.dtsi create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts -- 2.7.4
Re: [PATCH v4 28/34] KVM: arm64: Use page-table to track page ownership
On Thursday 11 Mar 2021 at 18:38:36 (+), Will Deacon wrote:
> On Wed, Mar 10, 2021 at 05:57:45PM +, Quentin Perret wrote:
> > As the host stage 2 will be identity mapped, all the .hyp memory regions
> > and/or memory pages donated to protected guestis will have to marked
> > invalid in the host stage 2 page-table. At the same time, the hypervisor
> > will need a way to track the ownership of each physical page to ensure
> > memory sharing or donation between entities (host, guests, hypervisor) is
> > legal.
> >
> > In order to enable this tracking at EL2, let's use the host stage 2
> > page-table itself. The idea is to use the top bits of invalid mappings
> > to store the unique identifier of the page owner. The page-table owner
> > (the host) gets identifier 0 such that, at boot time, it owns the entire
> > IPA space as the pgd starts zeroed.
> >
> > Provide kvm_pgtable_stage2_set_owner() which allows to modify the
> > ownership of pages in the host stage 2. It re-uses most of the map()
> > logic, but ends up creating invalid mappings instead. This impacts
> > how we do refcount as we now need to count invalid mappings when they
> > are used for ownership tracking.
> >
> > Signed-off-by: Quentin Perret
> > ---
> > arch/arm64/include/asm/kvm_pgtable.h | 21 +++
> > arch/arm64/kvm/hyp/pgtable.c | 92
> > 2 files changed, 101 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_pgtable.h
> > b/arch/arm64/include/asm/kvm_pgtable.h
> > index 4ae19247837b..b09af4612656 100644
> > --- a/arch/arm64/include/asm/kvm_pgtable.h
> > +++ b/arch/arm64/include/asm/kvm_pgtable.h
> > @@ -238,6 +238,27 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt,
> > u64 addr, u64 size,
> >u64 phys, enum kvm_pgtable_prot prot,
> >void *mc);
> >
> > +/**
> > + * kvm_pgtable_stage2_set_owner() - Annotate invalid mappings with metadata
> > + * encoding the ownership of a page in the
> > + * IPA space.
> > + * @pgt: Page-table structure initialised by kvm_pgtable_stage2_init().
> > + * @addr: Intermediate physical address at which to place the annotation.
>
> This confused me a bit, as the annotation is stored in the page-table, not
> at the memory identified by @addr. How about:
>
> "Base intermediate physical address to annotate"
>
> > + * @size: Size of the IPA range to annotate.
>
> "Size of the annotated range"
>
> > + * @mc:Cache of pre-allocated and zeroed memory from which to
> > allocate
> > + * page-table pages.
> > + * @owner_id: Unique identifier for the owner of the page.
> > + *
> > + * The page-table owner has identifier 0.
>
> Perhaps, "By default, all page-tables are owned by identifier 0"
Ack all of the above.
> > + *
> > + * Return: 0 on success, negative error code on failure.
> > + */
> > +int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64
> > size,
> > +void *mc, u32 owner_id);
>
> Is there a need for the owner_id to be 32-bit rather than e.g. 16-bit? Just
> strikes me that it might be difficult to recover these bits in future if we
> give them out freely now.
I figured we might want to use identifiers that are stable for the
lifetime of protected VMs. I wasn't sure using e.g. VMIDs would be a
better choice here as re-using them will cause a lot of pain for the
host stage 2 pgtable maintenance.
> > +
> > /**
> > * kvm_pgtable_stage2_unmap() - Remove a mapping from a guest stage-2
> > page-table.
> > * @pgt: Page-table structure initialised by kvm_pgtable_stage2_init().
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index f37b4179b880..e4670b639726 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > @@ -48,6 +48,8 @@
> > KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \
> > KVM_PTE_LEAF_ATTR_HI_S2_XN)
> >
> > +#define KVM_INVALID_PTE_OWNER_MASK GENMASK(63, 32)
>
> Ah, so that '02' earlier was a typo for '32'.
>
> > +
> > struct kvm_pgtable_walk_data {
> > struct kvm_pgtable *pgt;
> > struct kvm_pgtable_walker *walker;
> > @@ -186,6 +188,11 @@ static kvm_pte_t kvm_init_valid_leaf_pte(u64 pa,
> > kvm_pte_t attr, u32 level)
> > return pte;
> > }
> >
> > +static kvm_pte_t kvm_init_invalid_leaf_owner(u32 owner_id)
> > +{
> > + return FIELD_PREP(KVM_INVALID_PTE_OWNER_MASK, owner_id);
> > +}
> > +
> > static int kvm_pgtable_visitor_cb(struct kvm_pgtable_walk_data *data, u64
> > addr,
> > u32 level, kvm_pte_t *ptep,
> > enum kvm_pgtable_walk_flags flag)
> > @@ -440,6 +447,7 @@ void kvm_pgtable_hyp_destroy(struct kvm_pgtable *pgt)
> > struct stage2_map_data {
> > u64 phys;
Re: [PATCH v5 2/3] dt-bindings: mtd: Document use of nvmem-cells compatible
On 11.03.2021 11:50, Ansuel Smith wrote: On Thu, Mar 11, 2021 at 10:32:21AM -0700, Rob Herring wrote: On Thu, Mar 11, 2021 at 06:12:48AM +0100, Ansuel Smith wrote: Document nvmem-cells compatible used to treat mtd partitions as a nvmem provider. Signed-off-by: Ansuel Smith --- .../bindings/mtd/partitions/nvmem-cells.yaml | 99 +++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml new file mode 100644 index ..b53faf87d4e4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/nvmem-cells.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nvmem cells + +description: | + Any partition containing the compatible "nvmem-cells" will register as a + nvmem provider. + Each direct subnodes represents a nvmem cell following the nvmem binding. + Nvmem binding to declare nvmem-cells can be found in: + Documentation/devicetree/bindings/nvmem/nvmem.yaml + +maintainers: + - Ansuel Smith + +allOf: + - $ref: "../../nvmem/nvmem.yaml#" I'd rather have the 'absolute' path: /schemas/nvmem/nvmem.yaml Otherwise, Reviewed-by: Rob Herring Should I send a v7? Yes, please, let's make it the right way :) When sending V7 please: 1. Include above "Reviewed-by" in the "dt-bindings: mtd: Document use of nvmem-cells compatible" 2. Include my "Tested-by" in the "mtd: core: add nvmem-cells compatible to parse mtd as nvmem cells" Reference: [PATCH v2 2/3] mtd: core: add nvmem-partitions compatible to parse mtd as nvmem cells https://patchwork.ozlabs.org/project/linux-mtd/patch/20210216212638.28382-3-ansuels...@gmail.com/
Re: [PATCH 06/17] kthread: cfi: disable callback pointer check with modules
On Thu, Mar 11, 2021 at 04:49:08PM -0800, Sami Tolvanen wrote: > With CONFIG_CFI_CLANG, a callback function passed to > __kthread_queue_delayed_work from a module points to a jump table > entry defined in the module instead of the one used in the core > kernel, which breaks function address equality in this check: > > WARN_ON_ONCE(timer->function != kthread_delayed_work_timer_fn); > > Disable the warning when CFI and modules are enabled. > > Signed-off-by: Sami Tolvanen > --- > kernel/kthread.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/kernel/kthread.c b/kernel/kthread.c > index 1578973c5740..af5fee350586 100644 > --- a/kernel/kthread.c > +++ b/kernel/kthread.c > @@ -963,7 +963,13 @@ static void __kthread_queue_delayed_work(struct > kthread_worker *worker, > struct timer_list *timer = >timer; > struct kthread_work *work = >work; > > - WARN_ON_ONCE(timer->function != kthread_delayed_work_timer_fn); > + /* > + * With CFI, timer->function can point to a jump table entry in a > module, you keep spewing this comment line that has exactly 81 characters and thus badly messes up read it with a normal termina everywhere. Maybe instead of fixing that in ever duplication hide the whole check in a well documented helper (which would have to be a macro due to the typing involved).
Re: [PATCH v7] i2c: virtio: add a virtio i2c frontend driver
I saw your email about wrong version being sent, I already wrote some
reviews. Sending them anyway for FWIW :)
On 12-03-21, 21:33, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> new file mode 100644
> index 000..bbde8de
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-virtio.c
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Virtio I2C Bus Driver
> + *
> + * The Virtio I2C Specification:
> + *
> https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex
> + *
> + * Copyright (c) 2021 Intel Corporation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * struct virtio_i2c - virtio I2C data
> + * @vdev: virtio device for this controller
> + * @completion: completion of virtio I2C message
> + * @adap: I2C adapter for this controller
> + * @i2c_lock: lock for virtqueue processing
> + * @vq: the virtio virtqueue for communication
> + */
> +struct virtio_i2c {
> + struct virtio_device *vdev;
> + struct completion completion;
> + struct i2c_adapter adap;
> + struct mutex lock;
As I said in the previous version (Yes, we were both waiting for
Wolfram to answer that), this lock shouldn't be required at all.
And since none of us have a use-case at hand where we will have a
problem without this lock, we should really skip it. We can always
come back and add it if we find an issue somewhere. Until then, better
to keep it simple.
> + struct virtqueue *vq;
> +};
> +
> +/**
> + * struct virtio_i2c_req - the virtio I2C request structure
> + * @out_hdr: the OUT header of the virtio I2C message
> + * @buf: the buffer into which data is read, or from which it's written
> + * @in_hdr: the IN header of the virtio I2C message
> + */
> +struct virtio_i2c_req {
> + struct virtio_i2c_out_hdr out_hdr;
> + uint8_t *buf;
> + struct virtio_i2c_in_hdr in_hdr;
> +};
> +
> +static void virtio_i2c_msg_done(struct virtqueue *vq)
> +{
> + struct virtio_i2c *vi = vq->vdev->priv;
> +
> + complete(>completion);
> +}
> +
> +static int virtio_i2c_send_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
> +{
> + struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
> + int i, outcnt, incnt, err = 0;
> +
> + for (i = 0; i < nr; i++) {
> + if (!msgs[i].len)
> + break;
> +
> + /*
> + * Only 7-bit mode supported for this moment. For the address
> format,
> + * Please check the Virtio I2C Specification.
> + */
> + reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1);
> +
> + if (i != nr - 1)
> + reqs[i].out_hdr.flags =
> cpu_to_le32(VIRTIO_I2C_FLAGS_FAIL_NEXT);
> +
> + outcnt = incnt = 0;
> + sg_init_one(_hdr, [i].out_hdr,
> sizeof(reqs[i].out_hdr));
> + sgs[outcnt++] = _hdr;
> +
> + reqs[i].buf = i2c_get_dma_safe_msg_buf([i], 1);
> + if (!reqs[i].buf)
> + break;
> +
> + sg_init_one(_buf, reqs[i].buf, msgs[i].len);
> +
> + if (msgs[i].flags & I2C_M_RD)
> + sgs[outcnt + incnt++] = _buf;
> + else
> + sgs[outcnt++] = _buf;
> +
> + sg_init_one(_hdr, [i].in_hdr, sizeof(reqs[i].in_hdr));
> + sgs[outcnt + incnt++] = _hdr;
> +
> + err = virtqueue_add_sgs(vq, sgs, outcnt, incnt, [i],
> GFP_KERNEL);
> + if (err < 0) {
> + pr_err("failed to add msg[%d] to virtqueue.\n", i);
> + i2c_put_dma_safe_msg_buf(reqs[i].buf, [i], false);
> + break;
> + }
> + }
> +
> + return i;
> +}
> +
> +static int virtio_i2c_complete_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
> +{
> + struct virtio_i2c_req *req;
> + unsigned int len, unused;
> + int i, j;
> +
> + for (i = 0; i < nr; i++) {
> + req = virtqueue_get_buf(vq, );
> + if (!(req && req == [i])) {
> + pr_err("msg[%d]: addr=0x%x is out of order.\n", i,
> msgs[i].addr);
> + break;
> + }
> +
> + if (req->in_hdr.status != VIRTIO_I2C_MSG_OK) {
> + pr_err("msg[%d]: addr=0x%x backend error.\n", i,
> msgs[i].addr);
> + break;
> + }
> +
> + i2c_put_dma_safe_msg_buf(req->buf, [i], true);
> + }
> +
> + /* Release unused DMA safe buffer if any */
> + for (j = i; j < nr; j++)
> + i2c_put_dma_safe_msg_buf(req->buf, [j], false);
> +
> + /*
Re: [RFC 0/2] virtio-pmem: Asynchronous flush
On Thu, Mar 11, 2021 at 8:21 PM Pankaj Gupta wrote: > > Hi David, > > > > Jeff reported preflush order issue with the existing implementation > > > of virtio pmem preflush. Dan suggested[1] to implement asynchronous > > > flush > > > for virtio pmem using work queue as done in md/RAID. This patch series > > > intends to solve the preflush ordering issue and also makes the flush > > > asynchronous from the submitting thread POV. > > > > > > Submitting this patch series for feeback and is in WIP. I have > > > done basic testing and currently doing more testing. > > > > > > Pankaj Gupta (2): > > >pmem: make nvdimm_flush asynchronous > > >virtio_pmem: Async virtio-pmem flush > > > > > > drivers/nvdimm/nd_virtio.c | 66 ++-- > > > drivers/nvdimm/pmem.c| 15 > > > drivers/nvdimm/region_devs.c | 3 +- > > > drivers/nvdimm/virtio_pmem.c | 9 + > > > drivers/nvdimm/virtio_pmem.h | 12 +++ > > > 5 files changed, 78 insertions(+), 27 deletions(-) > > > > > > [1] https://marc.info/?l=linux-kernel=157446316409937=2 > > > > > > > Just wondering, was there any follow up of this or are we still waiting > > for feedback? :) > > Thank you for bringing this up. > > My apologies I could not followup on this. I have another version in my local > tree but could not post it as I was not sure if I solved the problem > correctly. I will > clean it up and post for feedback as soon as I can. > > P.S: Due to serious personal/family health issues I am not able to > devote much time > on this with other professional commitments. I feel bad that I have > this unfinished task. > Just in last one year things have not been stable for me & my family > and still not getting :( No worries Pankaj. Take care of yourself and your family. The community can handle this for you. I'm open to coaching somebody through what's involved to get this fix landed.
Re: [PATCH] leds: leds-dual-gpio: Add dual GPIO LEDs driver
On Fri, 12 Mar 2021 04:48:52 +
Hermes Zhang wrote:
> >
> > Sorry, leds-regulator has only a binary state LED.
> >
> > Maybe you could extend leds-regulator to be able to use all regulator
> > states?
> >
> > Or you can extend leds-gpio driver to support N states via log N gpios,
> > instead of adding new driver.
>
> It seems a good idea to extend leds-gpio, so in my case, I should have such
> dts:
>
> 63 leds {
> 64 compatible = "gpio-leds";
> 65
> 66 recording_front {
> 67 label = "recording_front:red";
> 68 gpios = < 130 GPIO_ACTIVE_HIGH>, < 129
> GPIO_ACTIVE_HIGH>;
> 69 default-state = "off";
> 70 };
> 71 };
>
> For my case, two leds is enough, but it sill easy to extend the support
> number bigger than two. And the length of gpios array is not fixed, so it
> could compatible with exist "gpio-leds" dts, right?
>
> If this idea work, should I create a new commit or still in this track (V2)?
However you want :)
Look at the states property of gpio regulator:
https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
It is possible to have a multi-GPIO LED which brightness is set via N
GPIOs and it has 2^N brightness states encoded by binary values of
those GPIOs, but it is entirely possible to have less than 2^N states,
or that the states are encoded in a different way.
In the first version though imlpemenent just the simplest case: N GPIOs
with 2^N states.
Marek
Re: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned
On Thu, 11 Mar 2021 17:05:53 + "Luck, Tony" wrote: > > I guess that p->mce_vaddr stores the virtual address of the error here. > > If so, sending SIGBUS with the address looks enough as we do now, so why > > do you walk page table to find the error virtual address? > > p->mce_vaddr only has the virtual address for the COPYIN case. In that code > path we decode the kernel instruction that hit the fault in order to find the > virtual > address. That's easy because: > > 1) The kernel RIP is known to be good (can't page fault etc. on kernel > address). > 2) There are only a half dozen instructions used by the kernel for get_user() > or > copy_from_user(). > > When the machine check happens during user execution accessing poison data > we only have the physical address (from MCi_ADDR). > > -Tony Sorry to interrupt as I am really confused here: If it's a copyin case, has the page been mapped for the current process? will memory_failure() find it and unmap it? if succeed, then the current will be signaled with correct vaddr and shift? Maybe the mce_vaddr is set correctly, but we may lost the correct page shift? And for copyin case, we don't need to call set_mce_nospec()? -- Thanks! Aili Yao
Re: [PATCH v7] i2c: virtio: add a virtio i2c frontend driver
Sorry , sent the wrong version. Please ignore this. I will resend.
