Message ID | 20230609164207.430377-1-hamza.mahfooz@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp1051659vqr; Fri, 9 Jun 2023 09:46:38 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4mhKnNwjdJWTpOg8o+HV4f2+HOpO/vvVgYrTm2Jv+t/D5jt2vI0AwG73xJjki9itgE1Hqa X-Received: by 2002:a05:6a00:1744:b0:65e:691a:460f with SMTP id j4-20020a056a00174400b0065e691a460fmr2018455pfc.8.1686329197941; Fri, 09 Jun 2023 09:46:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1686329197; cv=pass; d=google.com; s=arc-20160816; b=Vz2FzbSLDFQDHvQ1F/cXUXt7LxJX+VioJFyMJD0q+TA9lvoYc7KwJSzlivcMN4XZpR oe13vqwhcoKLi3E5bw2MXNIj0c6CzKM7rvVye4UPStR/ytysNEiGXOTlK3KkEhfVmS/G /DUxdCD7tO+f1VZIvrPtJRIVTI5emjldqc8Gp0xyOksj2wk+BQns27RvAJRUzghJMIwc GwripBBQSvR+m1onB7JW4CKg5UB5rkE8VWjlNQz27XwWHc3CY1v8an/Sb+OkhrI1AyGz d1xEbKxc/7/7tmVixtvIdIu/Rj37Im8fIlTuaIlnEpL8cfjCj3lW65OnWQCHRekZ4vLT oUVA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=MHPtUkjWi081Krft7qmVvihs5tNcNkdVbKJftJWFc3Y=; b=XAyKGJ0aWv43JY1zAnBXUCKgTYyWHIfdN2VZ6EZQtIX1Xvx7nwPedvVyPRpQrpnK4O zhrMJ0RVOJyPLBIVY9aS/67dqWimCPBoeLdnzDaZL3XTvWipoWzVTBOy7mnAjMJdCSrS 7YXYi98JjEv7PSRqg9r1RlXHsjXaRqRJVyaU7GExuHq1BzvdpOrhDLFu3C6oDW2GIyz4 OXxUzzvCMrOtVtLZtkudq1O/BSJgU7AmkLeEViCb+0mISwt2xCiHHFuFtF1gix62uInS YWTz2IoR/0LeQfkSsGzmY8x/K1H1wBjtAATzvoGwFil8Feqe/8D4kqoeVyCOnFMMZfeI Tk4Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=NSrrP+qz; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d7-20020aa797a7000000b00643c4d0d0f5si2783844pfq.39.2023.06.09.09.46.12; Fri, 09 Jun 2023 09:46:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=NSrrP+qz; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229488AbjFIQm3 (ORCPT <rfc822;liningstudo@gmail.com> + 99 others); Fri, 9 Jun 2023 12:42:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbjFIQm2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 9 Jun 2023 12:42:28 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2062d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe59::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40C5A3A88 for <linux-kernel@vger.kernel.org>; Fri, 9 Jun 2023 09:42:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YCn74W6oTKafdFplYyGGITWTFjy0y1+XVil81GgOgqC//ayfgsve7Brl0x5TxdAltVuRutslcq/ccx2XKSJPHyAKqtjq4npceBx32Ph8t/Zh8cBDmIHm5MwqcWjucf8Bx8RzO6qezwT5YopnoBhAnbATy5PA6M4QL0fEKJ3beE4mehtKdtFi0M4P7BMrRH8ixURpr9DSDf96WwgoWU1n0tPyOGPbzCLPlvGHIg5ygVNtfpHYVPSnBzErr8ecomjKTymVU91bDRZVfhXnnRY+QBkXQf6FKHS2gP4FhwrPehWZdNtym3cY/Upxxot79d0YLjPPbjUp0EyGbynQTzbWfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MHPtUkjWi081Krft7qmVvihs5tNcNkdVbKJftJWFc3Y=; b=NIFmxNtSCbP0CqZgWENemn2dghXIEb0ukPYruINW8c+ueUKn1Hg77FYZTEvSjt5wKS+aqxWsxCebcqMH1zRtFvGjJ8U+TMx4NgE1KqPOVrcuZ6haZvTIRPd2xK35f+q5Dxbjh4Jy2lY8mpJChpv17/9Rj4XS+m3O+Bygv/TiWN/FgbRZrjvy25zif4oWfifh2g425vubRpQ263OLxxJFnm3ImJT415R1RuIZodlyKBpPfl+y1WALgJjDDWYw9eRP/mjrrfbX1W5uckPMf2j/bEQDA4+k2eqTRRq3MFOdYilWNVPcE04AgjWUD9+FIKsH+g6d05qUStbbm0n/vtTGSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.freedesktop.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MHPtUkjWi081Krft7qmVvihs5tNcNkdVbKJftJWFc3Y=; b=NSrrP+qz16Ep0C2ej2gIC+3YpQPO3QIasFkEnVki3jM3YiDMtgZHZGvf3zLahWgA9d1O/zG5bvJy/F0CUmpTgSB19+gnvPkzkf4Z/MT4vNnsrrneoyL1JP/rYcZixvwuGjIGs8FZKOkcTpUaZpiB9ZNv9TVzesv9lt8M3Ievnos= Received: from CY5PR19CA0106.namprd19.prod.outlook.com (2603:10b6:930:83::29) by SA1PR12MB7039.namprd12.prod.outlook.com (2603:10b6:806:24e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6455.33; Fri, 9 Jun 2023 16:42:22 +0000 Received: from CY4PEPF0000EE30.namprd05.prod.outlook.com (2603:10b6:930:83:cafe::12) by CY5PR19CA0106.outlook.office365.com (2603:10b6:930:83::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6477.27 via Frontend Transport; Fri, 9 Jun 2023 16:42:22 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000EE30.mail.protection.outlook.com (10.167.242.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6477.13 via Frontend Transport; Fri, 9 Jun 2023 16:42:22 +0000 Received: from hamza-pc.localhost (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 9 Jun 2023 11:42:20 -0500 From: Hamza Mahfooz <hamza.mahfooz@amd.com> To: <amd-gfx@lists.freedesktop.org> CC: Hamza Mahfooz <hamza.mahfooz@amd.com>, Alex Deucher <alexander.deucher@amd.com>, Nathan Chancellor <nathan@kernel.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, "Pan, Xinhui" <Xinhui.Pan@amd.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Hawking Zhang <Hawking.Zhang@amd.com>, Le Ma <le.ma@amd.com>, Tao Zhou <tao.zhou1@amd.com>, YiPeng Chai <YiPeng.Chai@amd.com>, James Zhu <James.Zhu@amd.com>, Xiaojian Du <Xiaojian.Du@amd.com>, Lijo Lazar <lijo.lazar@amd.com>, <dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] drm/amd/amdgpu: enable W=1 for amdgpu Date: Fri, 9 Jun 2023 12:42:06 -0400 Message-ID: <20230609164207.430377-1-hamza.mahfooz@amd.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE30:EE_|SA1PR12MB7039:EE_ X-MS-Office365-Filtering-Correlation-Id: 1be8b222-a1c3-4be0-02c6-08db69087f6f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zBVnWriaQhsvc9gfoINUaNvc2Eond8NvJSZSNkcBvJS9iUx0C5z1dxQcIl/tJ5uD0IZ1lC4+3ZCumVAjghmN+u+SX/UL4tKauTx73Bsy4HgxmQfw2j8WzzTNXbHDibipJPzCrPNMkAd4o3M3bcEvMvxefF2Ng3D+loo8yC0Akd/Qge9vylk+dYNkES4FduPpyGJtE4KFOmbOTwcjGaGkiWCjs2ywhkvxebXhPThquLdXa6Q0LRs9S/Ee8ybZmnIpGFlTnjc05UC9jKHpG0uvBUgQFxVrO112QAtnJfbL7b48olsxQa7k+jEdOqykZ1k2kp4NN4D34AdnGWskaT9n9AjpAe05wtNSONxjClV92qoiPYYrHrY7ewFI3avJ7iLthfH1ABWRx+7t4q6xeGTf66D6SR9dqn7Ioks0+YdTalw1JzTcKAl1PFFQAwwSKkPUMMbc3Iy/ks1s/TuJQp8wvKsr1cohDTXmepMinDLxm+zALRHTaUNdGK4CvIU2OoVzXfStIaNjiT/OfYhy2yuBpu3ZKWEmvg/HvHVidnNlSjtM8ysh5ThLHJuVx0H3fW9ko16ZZcJoQrsQNLo8uljcx7urJjtoILPNPoWGsyym5y5L4vWkL7uT8yKzzRs8q0KQE0KSgvYi7xy1l3G5JPCxQMm3hTg0r5dmf+N7QDxR/9BvpDRo9Yb+WX4WEHzMH/iaIxVZ9XuDw/KffG3zuHrxtgMOZb4DpdC+NXuTWKzFT6UHmJjOmfHsyozAcpgtIPkmPoU/uIiTMNpmNyudREl8yJbQ58y+1sF4VaSojigkbU8HJ5zjewTaBZC4OqxTfKWL X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(4636009)(39860400002)(136003)(346002)(376002)(396003)(451199021)(46966006)(40470700004)(36840700001)(2906002)(336012)(82310400005)(40460700003)(6666004)(16526019)(26005)(1076003)(47076005)(83380400001)(40480700001)(36860700001)(426003)(2616005)(86362001)(186003)(36756003)(356005)(82740400003)(81166007)(44832011)(54906003)(5660300002)(316002)(41300700001)(478600001)(4326008)(8936002)(70586007)(6916009)(8676002)(70206006)(16060500005)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2023 16:42:22.0599 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1be8b222-a1c3-4be0-02c6-08db69087f6f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EE30.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7039 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768244324901780531?= X-GMAIL-MSGID: =?utf-8?q?1768244324901780531?= |
Series |
drm/amd/amdgpu: enable W=1 for amdgpu
|
|
Commit Message
Hamza Mahfooz
June 9, 2023, 4:42 p.m. UTC
We have a clean build with W=1 as of
commit 12a15dd589ac ("drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move
SYNAPTICS_DEVICE_ID into CONFIG_DRM_AMD_DC_DCN ifdef"). So, let's enable
these checks unconditionally for the entire module to catch these errors
during development.
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
---
drivers/gpu/drm/amd/amdgpu/Makefile | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
Comments
+ Masahiro and linux-kbuild On Fri, Jun 09, 2023 at 12:42:06PM -0400, Hamza Mahfooz wrote: > We have a clean build with W=1 as of > commit 12a15dd589ac ("drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move > SYNAPTICS_DEVICE_ID into CONFIG_DRM_AMD_DC_DCN ifdef"). So, let's enable > these checks unconditionally for the entire module to catch these errors > during development. > > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: Nathan Chancellor <nathan@kernel.org> > Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> I think this is fine, especially since it will help catch issues in amdgpu quickly and hopefully encourage developers to fix their problems before they make it to a tree with wider impact lika -next. However, this is now the third place that W=1 has been effectively enabled (i915 and btrfs are the other two I know of) and it would be nice if this was a little more unified, especially since it is not uncommon for the warnings under W=1 to shift around and keeping them unified will make maintainence over the longer term a little easier. I am not sure if this has been brought up in the past and I don't want to hold up this change but I suspect this sentiment of wanting to enable W=1 on a per-subsystem basis is going to continue to grow. Regardless, for clang 11.1.0 to 16.0.5, I see no warnings when building drivers/gpu/drm/amd/amdgpu/ with Arch Linux's configuration or allmodconfig. Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> > --- > drivers/gpu/drm/amd/amdgpu/Makefile | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile > index 86b833085f19..8d16f280b695 100644 > --- a/drivers/gpu/drm/amd/amdgpu/Makefile > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile > @@ -40,7 +40,18 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \ > -I$(FULL_AMD_PATH)/amdkfd > > subdir-ccflags-y := -Wextra > -subdir-ccflags-y += $(call cc-option, -Wunused-but-set-variable) > +subdir-ccflags-y += -Wunused > +subdir-ccflags-y += -Wmissing-prototypes > +subdir-ccflags-y += -Wmissing-declarations > +subdir-ccflags-y += -Wmissing-include-dirs > +subdir-ccflags-y += -Wold-style-definition > +subdir-ccflags-y += -Wmissing-format-attribute > +# Need this to avoid recursive variable evaluation issues > +cond-flags := $(call cc-option, -Wunused-but-set-variable) \ > + $(call cc-option, -Wunused-const-variable) \ > + $(call cc-option, -Wstringop-truncation) \ > + $(call cc-option, -Wpacked-not-aligned) > +subdir-ccflags-y += $(cond-flags) > subdir-ccflags-y += -Wno-unused-parameter > subdir-ccflags-y += -Wno-type-limits > subdir-ccflags-y += -Wno-sign-compare > -- > 2.40.1 >
On Sat, Jun 10, 2023 at 5:17 AM Nathan Chancellor <nathan@kernel.org> wrote: > > + Masahiro and linux-kbuild > > On Fri, Jun 09, 2023 at 12:42:06PM -0400, Hamza Mahfooz wrote: > > We have a clean build with W=1 as of > > commit 12a15dd589ac ("drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move > > SYNAPTICS_DEVICE_ID into CONFIG_DRM_AMD_DC_DCN ifdef"). So, let's enable > > these checks unconditionally for the entire module to catch these errors > > during development. > > > > Cc: Alex Deucher <alexander.deucher@amd.com> > > Cc: Nathan Chancellor <nathan@kernel.org> > > Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> > > I think this is fine, especially since it will help catch issues in > amdgpu quickly and hopefully encourage developers to fix their problems > before they make it to a tree with wider impact lika -next. > > However, this is now the third place that W=1 has been effectively > enabled (i915 and btrfs are the other two I know of) and it would be > nice if this was a little more unified, especially since it is not > uncommon for the warnings under W=1 to shift around and keeping them > unified will make maintainence over the longer term a little easier. I > am not sure if this has been brought up in the past and I don't want to > hold up this change but I suspect this sentiment of wanting to enable > W=1 on a per-subsystem basis is going to continue to grow. I believe this patch is the right way because we will be able to add a new warning option to scripts/Makefile.extrawarn without fixing any code. I remember somebody argued that drivers should be able to do subdir-ccflags-y += $(W1_FLAGS) However, if a new flag, -Wfoo, emits warnings for drivers/gpu/drm/{i915,amd}, you cannot add it to W=1 until fixing the code. If many drivers start to do likewise, W=1 warning will not be W=1 any more. Another good thing for hard-coding warning options is you can lift up a warning flag one by one. Let's say you fixed the entire DRM subsystem so it is -Wunused free now. Then, you can move -Wunused to drivers/gpu/drm/Makefile, while other warning options stay in drivers Makefiles. > > Regardless, for clang 11.1.0 to 16.0.5, I see no warnings when building > drivers/gpu/drm/amd/amdgpu/ with Arch Linux's configuration or > allmodconfig. > > Reviewed-by: Nathan Chancellor <nathan@kernel.org> > Tested-by: Nathan Chancellor <nathan@kernel.org> > > > --- > > drivers/gpu/drm/amd/amdgpu/Makefile | 13 ++++++++++++- > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile > > index 86b833085f19..8d16f280b695 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/Makefile > > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile > > @@ -40,7 +40,18 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \ > > -I$(FULL_AMD_PATH)/amdkfd > > > > subdir-ccflags-y := -Wextra > > -subdir-ccflags-y += $(call cc-option, -Wunused-but-set-variable) > > +subdir-ccflags-y += -Wunused > > +subdir-ccflags-y += -Wmissing-prototypes > > +subdir-ccflags-y += -Wmissing-declarations > > +subdir-ccflags-y += -Wmissing-include-dirs > > +subdir-ccflags-y += -Wold-style-definition > > +subdir-ccflags-y += -Wmissing-format-attribute > > +# Need this to avoid recursive variable evaluation issues > > +cond-flags := $(call cc-option, -Wunused-but-set-variable) \ > > + $(call cc-option, -Wunused-const-variable) \ > > + $(call cc-option, -Wstringop-truncation) \ > > + $(call cc-option, -Wpacked-not-aligned) > > +subdir-ccflags-y += $(cond-flags) > > subdir-ccflags-y += -Wno-unused-parameter > > subdir-ccflags-y += -Wno-type-limits > > subdir-ccflags-y += -Wno-sign-compare > > -- > > 2.40.1 > >
On Sat, 10 Jun 2023, Masahiro Yamada <masahiroy@kernel.org> wrote: > On Sat, Jun 10, 2023 at 5:17 AM Nathan Chancellor <nathan@kernel.org> wrote: >> >> + Masahiro and linux-kbuild >> >> On Fri, Jun 09, 2023 at 12:42:06PM -0400, Hamza Mahfooz wrote: >> > We have a clean build with W=1 as of >> > commit 12a15dd589ac ("drm/amd/display/amdgpu_dm/amdgpu_dm_helpers: Move >> > SYNAPTICS_DEVICE_ID into CONFIG_DRM_AMD_DC_DCN ifdef"). So, let's enable >> > these checks unconditionally for the entire module to catch these errors >> > during development. >> > >> > Cc: Alex Deucher <alexander.deucher@amd.com> >> > Cc: Nathan Chancellor <nathan@kernel.org> >> > Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> >> >> I think this is fine, especially since it will help catch issues in >> amdgpu quickly and hopefully encourage developers to fix their problems >> before they make it to a tree with wider impact lika -next. >> >> However, this is now the third place that W=1 has been effectively >> enabled (i915 and btrfs are the other two I know of) and it would be >> nice if this was a little more unified, especially since it is not >> uncommon for the warnings under W=1 to shift around and keeping them >> unified will make maintainence over the longer term a little easier. I >> am not sure if this has been brought up in the past and I don't want to >> hold up this change but I suspect this sentiment of wanting to enable >> W=1 on a per-subsystem basis is going to continue to grow. > > > > I believe this patch is the right way because > we will be able to add a new warning option to > scripts/Makefile.extrawarn without fixing any code. > > I remember somebody argued that drivers should be > able to do > subdir-ccflags-y += $(W1_FLAGS) Personally, I think this would be the viable way to make the kernel free of W=1 warnings. Make it clean driver and subsystem at a time, with constant progress. Currently, there's haphazard fixing of issues, with new ones creeping back in, because kernel-wide W=1 is too verbose for most developers. It's whac-a-mole. > However, if a new flag, -Wfoo, emits warnings > for drivers/gpu/drm/{i915,amd}, > you cannot add it to W=1 until fixing the code. Or adding -Wno-foo where it breaks, until fixed. > If many drivers start to do likewise, > W=1 warning will not be W=1 any more. I don't know, is the goal to fix the warnings, or keep adding stuff to W=1 so that it'll always emit warnings? :p BR, Jani. > Another good thing for hard-coding warning options > is you can lift up a warning flag one by one. > > > Let's say you fixed the entire DRM subsystem so > it is -Wunused free now. > > Then, you can move -Wunused to drivers/gpu/drm/Makefile, > while other warning options stay in drivers Makefiles. > > > > > > > >> >> Regardless, for clang 11.1.0 to 16.0.5, I see no warnings when building >> drivers/gpu/drm/amd/amdgpu/ with Arch Linux's configuration or >> allmodconfig. >> >> Reviewed-by: Nathan Chancellor <nathan@kernel.org> >> Tested-by: Nathan Chancellor <nathan@kernel.org> >> >> > --- >> > drivers/gpu/drm/amd/amdgpu/Makefile | 13 ++++++++++++- >> > 1 file changed, 12 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile >> > index 86b833085f19..8d16f280b695 100644 >> > --- a/drivers/gpu/drm/amd/amdgpu/Makefile >> > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile >> > @@ -40,7 +40,18 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \ >> > -I$(FULL_AMD_PATH)/amdkfd >> > >> > subdir-ccflags-y := -Wextra >> > -subdir-ccflags-y += $(call cc-option, -Wunused-but-set-variable) >> > +subdir-ccflags-y += -Wunused >> > +subdir-ccflags-y += -Wmissing-prototypes >> > +subdir-ccflags-y += -Wmissing-declarations >> > +subdir-ccflags-y += -Wmissing-include-dirs >> > +subdir-ccflags-y += -Wold-style-definition >> > +subdir-ccflags-y += -Wmissing-format-attribute >> > +# Need this to avoid recursive variable evaluation issues >> > +cond-flags := $(call cc-option, -Wunused-but-set-variable) \ >> > + $(call cc-option, -Wunused-const-variable) \ >> > + $(call cc-option, -Wstringop-truncation) \ >> > + $(call cc-option, -Wpacked-not-aligned) >> > +subdir-ccflags-y += $(cond-flags) >> > subdir-ccflags-y += -Wno-unused-parameter >> > subdir-ccflags-y += -Wno-type-limits >> > subdir-ccflags-y += -Wno-sign-compare >> > -- >> > 2.40.1 >> >
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile index 86b833085f19..8d16f280b695 100644 --- a/drivers/gpu/drm/amd/amdgpu/Makefile +++ b/drivers/gpu/drm/amd/amdgpu/Makefile @@ -40,7 +40,18 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \ -I$(FULL_AMD_PATH)/amdkfd subdir-ccflags-y := -Wextra -subdir-ccflags-y += $(call cc-option, -Wunused-but-set-variable) +subdir-ccflags-y += -Wunused +subdir-ccflags-y += -Wmissing-prototypes +subdir-ccflags-y += -Wmissing-declarations +subdir-ccflags-y += -Wmissing-include-dirs +subdir-ccflags-y += -Wold-style-definition +subdir-ccflags-y += -Wmissing-format-attribute +# Need this to avoid recursive variable evaluation issues +cond-flags := $(call cc-option, -Wunused-but-set-variable) \ + $(call cc-option, -Wunused-const-variable) \ + $(call cc-option, -Wstringop-truncation) \ + $(call cc-option, -Wpacked-not-aligned) +subdir-ccflags-y += $(cond-flags) subdir-ccflags-y += -Wno-unused-parameter subdir-ccflags-y += -Wno-type-limits subdir-ccflags-y += -Wno-sign-compare