Message ID | 20240128-fix-clang-warnings-v1-3-1d946013a421@chromium.org (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Hans Verkuil |
Headers |
Received: from sv.mirrors.kernel.org ([139.178.88.99]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-4286-patchwork=linuxtv.org@vger.kernel.org>) id 1rTufX-000243-3D for patchwork@linuxtv.org; Sun, 28 Jan 2024 02:13:12 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 4E1412838F6 for <patchwork@linuxtv.org>; Sun, 28 Jan 2024 02:13:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C7763944F; Sun, 28 Jan 2024 02:12:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="cv1kF7YQ" X-Original-To: linux-media@vger.kernel.org Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 046D7523A for <linux-media@vger.kernel.org>; Sun, 28 Jan 2024 02:12:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706407947; cv=none; b=Y7NsMoFqv5KrxL6i20XZsoYMhU5A8yc8Wnf+7tsLlQ6QOKl9Ili/pWDAKRGalq+DyXzoSxQUuPbFt2TNkoIyCAReDjNXAQxhA/h0MvVTZeGu+UJOt0fcGeH6j9v904qshS7O42p8PFF9k/a/9RbgCpmJj87sn/7mj2kJmE2tWXw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706407947; c=relaxed/simple; bh=9FkkM0hWSfNgvycjkBk9G6d+gbIZbwtTlwMJBT/mtG4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=j1fgJsXNIaDH3TWIvIg7LlPHwUhfpl6fWKJge/pj8BvNjOcwA/mhw99J+VnZHX6mUYxrtWuRgv7Xv1xKmi55PrrpiX8kIxK5SbcDPseXg90g1Aqp/UUubyNkrPj64PH7JhqzPNLNekBqucNF9hmq3iaqe22ZMWnJv1CunITXSs8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=cv1kF7YQ; arc=none smtp.client-ip=209.85.160.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-42a8af3c724so4893251cf.2 for <linux-media@vger.kernel.org>; Sat, 27 Jan 2024 18:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706407945; x=1707012745; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=j3C7WQBZgNLZ3JFZZb+3FA3visUd8j+r0zGWZyg3Ybg=; b=cv1kF7YQM5NyC7/Jeh3KhL1qC/id6nz8hCXK0zJzhm7e1QGAwpIJCYF0dg6PoR0CyK sfVoLuXKp+C7E2VFBWxbrVZsg70FX+8gJT9hQP1KicVB9ejLwEZBueXnlyIC1TZNKdn+ FgkdKDKqXmHzMsWOMz6AvdkjUvT8wugbh+RL0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706407945; x=1707012745; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j3C7WQBZgNLZ3JFZZb+3FA3visUd8j+r0zGWZyg3Ybg=; b=EEZStR0ZHmGSnVzTg7oL0VgIF90ZeIGStHUBnQ6S2dzeZIcK8mD1lr3i9QlPymXkBL m1mDSWbsonUj1uJnDd2BWFYFBQkNz6POAG7iwjm5CQonwyfnTgOcMHx1Rn3QqT7zITxo n/412T+NDB6/DSZsfRiQ7iSF4vyIp/nDMmJkestC1mNkt9OmhXdflyedRblLD8fkkKRQ 834ofy/6wAcMAACrB+mIfRjIhXw8+V7LQMGMtPNrt6Wq6ielqFtpwjxH/S4AEW2BE9Ee onITq07JHi0r5OaBi8/I9fNOwssTl+hy/na92sf32rGmN9e46eD0iX7c4rzqkEWsgCd6 Pkiw== X-Gm-Message-State: AOJu0YwBCtvxWvf0UG0s5QXlBu7LBH0ppJ8xArYG97VWLj6iejO7QKgX IGX+gdhsJJpGLGzkrVgoIl+7BZf2tvlBYct8UxFnTeOqy8VR4+l0LWefD7BdpA== X-Google-Smtp-Source: AGHT+IFQh4FaJ+1XI2IdQ76ww3xRTWTulNHZ3WBhfnSPiasZomtas55CswgU5xylWxHtrHsOrzM/jg== X-Received: by 2002:ac8:4e96:0:b0:42a:87ff:4b0a with SMTP id 22-20020ac84e96000000b0042a87ff4b0amr4978445qtp.99.1706407944870; Sat, 27 Jan 2024 18:12:24 -0800 (PST) Received: from denia.c.googlers.com (240.157.150.34.bc.googleusercontent.com. [34.150.157.240]) by smtp.gmail.com with ESMTPSA id ka23-20020a05622a441700b0042a98bf0117sm568061qtb.78.2024.01.27.18.12.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jan 2024 18:12:24 -0800 (PST) From: Ricardo Ribalda <ribalda@chromium.org> Date: Sun, 28 Jan 2024 02:12:22 +0000 Subject: [PATCH 3/3] media: mediatek: vcodedc: Fix Wcast-function-type-strict warnings Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240128-fix-clang-warnings-v1-3-1d946013a421@chromium.org> References: <20240128-fix-clang-warnings-v1-0-1d946013a421@chromium.org> In-Reply-To: <20240128-fix-clang-warnings-v1-0-1d946013a421@chromium.org> To: Mauro Carvalho Chehab <mchehab@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Bill Wendling <morbo@google.com>, Justin Stitt <justinstitt@google.com>, Mike Isely <isely@pobox.com>, Tiffany Lin <tiffany.lin@mediatek.com>, Andrew-CT Chen <andrew-ct.chen@mediatek.com>, Yunfei Dong <yunfei.dong@mediatek.com>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Ricardo Ribalda <ribalda@chromium.org> X-Mailer: b4 0.12.3 X-LSpam-Score: -4.0 (----) X-LSpam-Report: No, score=-4.0 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,DKIMWL_WL_HIGH=-1,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_MED=-2.3,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no |
Series |
media: Fix warnings building with LLVM=1
|
|
Commit Message
Ricardo Ribalda
Jan. 28, 2024, 2:12 a.m. UTC
Building with LLVM=1 throws the following warning:
drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Wcast-function-type-strict]
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
---
drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On Sun, Jan 28, 2024 at 02:12:22AM +0000, Ricardo Ribalda wrote: > Building with LLVM=1 throws the following warning: > drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Wcast-function-type-strict] > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> I am not positive because I don't have any hardware to test this driver but I suspect this patch is just hiding the warning without actually addressing the issue that it is pointing out. If handler is called through vpu_ipi_register() indirectly (which it obviously is if it is being passed down), there will be a CFI failure because the type of mtk_vcodec_ipi_handler is not the same as ipi_handler_t, as the comment mentions. Has this seen testing on real hardware with kCFI? > --- > drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c > index 9f6e4b59455d..781a0359afdc 100644 > --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c > +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c > @@ -33,9 +33,11 @@ static int mtk_vcodec_vpu_set_ipi_register(struct mtk_vcodec_fw *fw, int id, > * The handler we receive takes a void * as its first argument. We > * cannot change this because it needs to be passed down to the rproc > * subsystem when SCP is used. VPU takes a const argument, which is > - * more constrained, so the conversion below is safe. > + * more constrained, so the conversion below is safe. We use the void > + * casting, to convince clang with -Wcast-function-type-sctrict that > + * this is safe. > */ > - ipi_handler_t handler_const = (ipi_handler_t)handler; > + ipi_handler_t handler_const = (ipi_handler_t)((void *)handler); > > return vpu_ipi_register(fw->pdev, id, handler_const, name, priv); > } > > -- > 2.43.0.429.g432eaa2c6b-goog >
On Thu, Feb 1, 2024 at 10:17 PM Nathan Chancellor <nathan@kernel.org> wrote: > > On Sun, Jan 28, 2024 at 02:12:22AM +0000, Ricardo Ribalda wrote: > > Building with LLVM=1 throws the following warning: > > drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Wcast-function-type-strict] > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > > I am not positive because I don't have any hardware to test this driver > but I suspect this patch is just hiding the warning without actually > addressing the issue that it is pointing out. Agreed, this won't fix the issue. The correct solution is to drop the cast and change the handler type to match the pointer type (i.e. use const void* for the first argument). Sami
Il 01/02/24 23:25, Sami Tolvanen ha scritto: > On Thu, Feb 1, 2024 at 10:17 PM Nathan Chancellor <nathan@kernel.org> wrote: >> >> On Sun, Jan 28, 2024 at 02:12:22AM +0000, Ricardo Ribalda wrote: >>> Building with LLVM=1 throws the following warning: >>> drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Wcast-function-type-strict] >>> >>> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> >> >> I am not positive because I don't have any hardware to test this driver >> but I suspect this patch is just hiding the warning without actually >> addressing the issue that it is pointing out. > > Agreed, this won't fix the issue. The correct solution is to drop the > cast and change the handler type to match the pointer type (i.e. use > const void* for the first argument). > Even though I agree that the correct solution is to change the handler's type, I think that having a test on the actual hardware done is still valuable. We scheduled a job on KernelCI to test this commit on our integration kernel, you'll get results for ChromeOS' tast decoders (MT8195 only) and Fluster tests on MT8183/8186/8192/8195. The results should be available in a couple of hours here, relative to commit `49955a84129dbe1f94fedf729690efcf28513828` on our tree: https://chromeos.kernelci.org/job/collabora-chromeos-kernel/branch/for-kernelci/ P.S.: If they don't, feel free to ping me or Nicolas (added to the loop) about it. Cheers, Angelo
On Fri, Feb 02, 2024 at 01:58:05PM +0100, AngeloGioacchino Del Regno wrote: > Il 01/02/24 23:25, Sami Tolvanen ha scritto: > > On Thu, Feb 1, 2024 at 10:17 PM Nathan Chancellor <nathan@kernel.org> wrote: > > > > > > On Sun, Jan 28, 2024 at 02:12:22AM +0000, Ricardo Ribalda wrote: > > > > Building with LLVM=1 throws the following warning: > > > > drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Wcast-function-type-strict] > > > > > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > > > > > > I am not positive because I don't have any hardware to test this driver > > > but I suspect this patch is just hiding the warning without actually > > > addressing the issue that it is pointing out. > > > > Agreed, this won't fix the issue. The correct solution is to drop the > > cast and change the handler type to match the pointer type (i.e. use > > const void* for the first argument). > > > > Even though I agree that the correct solution is to change the handler's type, > I think that having a test on the actual hardware done is still valuable. > > We scheduled a job on KernelCI to test this commit on our integration kernel, > you'll get results for ChromeOS' tast decoders (MT8195 only) and Fluster tests > on MT8183/8186/8192/8195. > > > The results should be available in a couple of hours here, relative to > commit `49955a84129dbe1f94fedf729690efcf28513828` on our tree: > https://chromeos.kernelci.org/job/collabora-chromeos-kernel/branch/for-kernelci/ > > P.S.: If they don't, feel free to ping me or Nicolas (added to the loop) about it. Hi, the results are available at https://chromeos.kernelci.org/test/job/collabora-chromeos-kernel/branch/for-kernelci/kernel/v6.8-rc2-3109-g49955a84129d/ (You need to type "decoder" into the search bar to limit the results to only the decoder tests) The only regressions I see are due to infrastructure error or broken test unrelated to this change (v4l2-decoder-conformance-h264-frext test on MT8195-Tomato, and cros-tast-decoder-v4l2-sl-h264 test on MT8183-Juniper) Otherwise, all platforms (MT8183/8186/8192/8195) and video codecs (VP8/VP9/H264/H265/AV1) seem unaffected. Note that these are GCC builds. Thanks, Nícolas
On Fri, Feb 02, 2024 at 03:15:46PM -0500, Nícolas F. R. A. Prado wrote: > On Fri, Feb 02, 2024 at 01:58:05PM +0100, AngeloGioacchino Del Regno wrote: > > Il 01/02/24 23:25, Sami Tolvanen ha scritto: > > > On Thu, Feb 1, 2024 at 10:17 PM Nathan Chancellor <nathan@kernel.org> wrote: > > > > > > > > On Sun, Jan 28, 2024 at 02:12:22AM +0000, Ricardo Ribalda wrote: > > > > > Building with LLVM=1 throws the following warning: > > > > > drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Wcast-function-type-strict] > > > > > > > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > > > > > > > > I am not positive because I don't have any hardware to test this driver > > > > but I suspect this patch is just hiding the warning without actually > > > > addressing the issue that it is pointing out. > > > > > > Agreed, this won't fix the issue. The correct solution is to drop the > > > cast and change the handler type to match the pointer type (i.e. use > > > const void* for the first argument). > > > > > > > Even though I agree that the correct solution is to change the handler's type, > > I think that having a test on the actual hardware done is still valuable. > > > > We scheduled a job on KernelCI to test this commit on our integration kernel, > > you'll get results for ChromeOS' tast decoders (MT8195 only) and Fluster tests > > on MT8183/8186/8192/8195. > > > > > > The results should be available in a couple of hours here, relative to > > commit `49955a84129dbe1f94fedf729690efcf28513828` on our tree: > > https://chromeos.kernelci.org/job/collabora-chromeos-kernel/branch/for-kernelci/ > > > > P.S.: If they don't, feel free to ping me or Nicolas (added to the loop) about it. > > Hi, > > the results are available at > > https://chromeos.kernelci.org/test/job/collabora-chromeos-kernel/branch/for-kernelci/kernel/v6.8-rc2-3109-g49955a84129d/ > > (You need to type "decoder" into the search bar to limit the results to only the > decoder tests) > > The only regressions I see are due to infrastructure error or broken test > unrelated to this change (v4l2-decoder-conformance-h264-frext test on > MT8195-Tomato, and cros-tast-decoder-v4l2-sl-h264 test on MT8183-Juniper) > > Otherwise, all platforms (MT8183/8186/8192/8195) and video codecs > (VP8/VP9/H264/H265/AV1) seem unaffected. > > Note that these are GCC builds. Thank you for running the tests to make sure this series does not regress anything. If possible, it would be good to try and build with LLVM and enable kernel Control Flow Integrity (kCFI, CONFIG_CFI_CLANG) to see if my theory that this is currently broken is correct. I have prebuilt LLVM toolchains on kernel.org but if it is too much of a hassle, I would not worry about it. https://mirrors.edge.kernel.org/pub/tools/llvm/ Cheers, Nathan
On Sun, Feb 04, 2024 at 01:55:49PM -0700, Nathan Chancellor wrote: > On Fri, Feb 02, 2024 at 03:15:46PM -0500, Nícolas F. R. A. Prado wrote: > > On Fri, Feb 02, 2024 at 01:58:05PM +0100, AngeloGioacchino Del Regno wrote: > > > Il 01/02/24 23:25, Sami Tolvanen ha scritto: > > > > On Thu, Feb 1, 2024 at 10:17 PM Nathan Chancellor <nathan@kernel.org> wrote: > > > > > > > > > > On Sun, Jan 28, 2024 at 02:12:22AM +0000, Ricardo Ribalda wrote: > > > > > > Building with LLVM=1 throws the following warning: > > > > > > drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, void *)') converts to incompatible function type [-Wcast-function-type-strict] > > > > > > > > > > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> > > > > > > > > > > I am not positive because I don't have any hardware to test this driver > > > > > but I suspect this patch is just hiding the warning without actually > > > > > addressing the issue that it is pointing out. > > > > > > > > Agreed, this won't fix the issue. The correct solution is to drop the > > > > cast and change the handler type to match the pointer type (i.e. use > > > > const void* for the first argument). > > > > > > > > > > Even though I agree that the correct solution is to change the handler's type, > > > I think that having a test on the actual hardware done is still valuable. > > > > > > We scheduled a job on KernelCI to test this commit on our integration kernel, > > > you'll get results for ChromeOS' tast decoders (MT8195 only) and Fluster tests > > > on MT8183/8186/8192/8195. > > > > > > > > > The results should be available in a couple of hours here, relative to > > > commit `49955a84129dbe1f94fedf729690efcf28513828` on our tree: > > > https://chromeos.kernelci.org/job/collabora-chromeos-kernel/branch/for-kernelci/ > > > > > > P.S.: If they don't, feel free to ping me or Nicolas (added to the loop) about it. > > > > Hi, > > > > the results are available at > > > > https://chromeos.kernelci.org/test/job/collabora-chromeos-kernel/branch/for-kernelci/kernel/v6.8-rc2-3109-g49955a84129d/ > > > > (You need to type "decoder" into the search bar to limit the results to only the > > decoder tests) > > > > The only regressions I see are due to infrastructure error or broken test > > unrelated to this change (v4l2-decoder-conformance-h264-frext test on > > MT8195-Tomato, and cros-tast-decoder-v4l2-sl-h264 test on MT8183-Juniper) > > > > Otherwise, all platforms (MT8183/8186/8192/8195) and video codecs > > (VP8/VP9/H264/H265/AV1) seem unaffected. > > > > Note that these are GCC builds. > > Thank you for running the tests to make sure this series does not > regress anything. If possible, it would be good to try and build with > LLVM and enable kernel Control Flow Integrity (kCFI, CONFIG_CFI_CLANG) > to see if my theory that this is currently broken is correct. I have > prebuilt LLVM toolchains on kernel.org but if it is too much of a > hassle, I would not worry about it. We don't have a way in KernelCI to run a one-off test, instead we need to make a PR adding a build definition that will be triggered for every update on a given tree. The results I reported above were for configurations that we already had in place. That said, maybe we should be running with LLVM and CONFIG_CFI_CLANG enabled on a regular basis, if you think it is useful as a general tool for identifying issues. I'd also be interested in hearing more from you on what other kind of clang configs you think might be good to enable in CI to provide value to the community. Thanks, Nícolas
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c index 9f6e4b59455d..781a0359afdc 100644 --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c @@ -33,9 +33,11 @@ static int mtk_vcodec_vpu_set_ipi_register(struct mtk_vcodec_fw *fw, int id, * The handler we receive takes a void * as its first argument. We * cannot change this because it needs to be passed down to the rproc * subsystem when SCP is used. VPU takes a const argument, which is - * more constrained, so the conversion below is safe. + * more constrained, so the conversion below is safe. We use the void + * casting, to convince clang with -Wcast-function-type-sctrict that + * this is safe. */ - ipi_handler_t handler_const = (ipi_handler_t)handler; + ipi_handler_t handler_const = (ipi_handler_t)((void *)handler); return vpu_ipi_register(fw->pdev, id, handler_const, name, priv); }