| Message ID | 20230824073710.2677348-1-lee@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Rid W=1 warnings from GPU | expand |
On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: amd-gfx@lists.freedesktop.org > Cc: Ben Skeggs <bskeggs@redhat.com> > Cc: "Christian König" <christian.koenig@amd.com> > Cc: Daniel Vetter <daniel@ffwll.ch> > Cc: Danilo Krummrich <dakr@redhat.com> > Cc: David Airlie <airlied@gmail.com> > Cc: dri-devel@lists.freedesktop.org > Cc: Fabio Estevam <festevam@gmail.com> > Cc: Gourav Samaiya <gsamaiya@nvidia.com> > Cc: Hawking Zhang <Hawking.Zhang@amd.com> > Cc: Hyun Kwon <hyun.kwon@xilinx.com> > Cc: Jerome Glisse <glisse@freedesktop.org> > Cc: Jonathan Hunter <jonathanh@nvidia.com> > Cc: Karol Herbst <kherbst@redhat.com> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Cc: linaro-mm-sig@lists.linaro.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-media@vger.kernel.org > Cc: linux-tegra@vger.kernel.org > Cc: Luben Tuikov <luben.tuikov@amd.com> > Cc: Lyude Paul <lyude@redhat.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: "Maíra Canal" <mairacanal@riseup.net> > Cc: Mario Limonciello <mario.limonciello@amd.com> > Cc: Maxime Ripard <mripard@kernel.org> > Cc: Michal Simek <michal.simek@xilinx.com> > Cc: Mikko Perttunen <mperttunen@nvidia.com> > Cc: nouveau@lists.freedesktop.org > Cc: NXP Linux Team <linux-imx@nxp.com> > Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> > Cc: Pengutronix Kernel Team <kernel@pengutronix.de> > Cc: Philipp Zabel <p.zabel@pengutronix.de> > Cc: Sascha Hauer <s.hauer@pengutronix.de> > Cc: Shashank Sharma <shashank.sharma@amd.com> > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Stanley Yang <Stanley.Yang@amd.com> > Cc: Sumit Semwal <sumit.semwal@linaro.org> > Cc: Thierry Reding <thierry.reding@gmail.com> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > [...] Applied to drm/drm-misc (drm-misc-fixes). Thanks! Maxime
Hi, On Thu, Aug 24, 2023 at 10:59:54AM +0200, Maxime Ripard wrote: > On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > Cc: Alex Deucher <alexander.deucher@amd.com> > > Cc: amd-gfx@lists.freedesktop.org > > Cc: Ben Skeggs <bskeggs@redhat.com> > > Cc: "Christian König" <christian.koenig@amd.com> > > Cc: Daniel Vetter <daniel@ffwll.ch> > > Cc: Danilo Krummrich <dakr@redhat.com> > > Cc: David Airlie <airlied@gmail.com> > > Cc: dri-devel@lists.freedesktop.org > > Cc: Fabio Estevam <festevam@gmail.com> > > Cc: Gourav Samaiya <gsamaiya@nvidia.com> > > Cc: Hawking Zhang <Hawking.Zhang@amd.com> > > Cc: Hyun Kwon <hyun.kwon@xilinx.com> > > Cc: Jerome Glisse <glisse@freedesktop.org> > > Cc: Jonathan Hunter <jonathanh@nvidia.com> > > Cc: Karol Herbst <kherbst@redhat.com> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > Cc: linaro-mm-sig@lists.linaro.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-media@vger.kernel.org > > Cc: linux-tegra@vger.kernel.org > > Cc: Luben Tuikov <luben.tuikov@amd.com> > > Cc: Lyude Paul <lyude@redhat.com> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Cc: "Maíra Canal" <mairacanal@riseup.net> > > Cc: Mario Limonciello <mario.limonciello@amd.com> > > Cc: Maxime Ripard <mripard@kernel.org> > > Cc: Michal Simek <michal.simek@xilinx.com> > > Cc: Mikko Perttunen <mperttunen@nvidia.com> > > Cc: nouveau@lists.freedesktop.org > > Cc: NXP Linux Team <linux-imx@nxp.com> > > Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> > > Cc: Pengutronix Kernel Team <kernel@pengutronix.de> > > Cc: Philipp Zabel <p.zabel@pengutronix.de> > > Cc: Sascha Hauer <s.hauer@pengutronix.de> > > Cc: Shashank Sharma <shashank.sharma@amd.com> > > Cc: Shawn Guo <shawnguo@kernel.org> > > Cc: Stanley Yang <Stanley.Yang@amd.com> > > Cc: Sumit Semwal <sumit.semwal@linaro.org> > > Cc: Thierry Reding <thierry.reding@gmail.com> > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > > > [...] > > Applied to drm/drm-misc (drm-misc-fixes). I got confused with b4 usage, but that wasn't actually applied. Only the three patches I explicitly mentioned were, sorry for the confusion. Maxime
On Thu, 24 Aug 2023, Lee Jones <lee@kernel.org> wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. The next question is, how do we keep it W=1 clean going forward? Most people don't use W=1 because it's too noisy, so it's a bit of a catch-22. In i915, we enable a lot of W=1 warnings using subdir-ccflags-y in our Makefile. For CI/developer use we also enable kernel-doc warnings by default. Should we start enabling some of those warning flags in drm/Makefile to to keep the entire subsystem warning free? BR, Jani.
On Thu, Aug 24, 2023 at 12:03:20PM +0300, Jani Nikula wrote: > On Thu, 24 Aug 2023, Lee Jones <lee@kernel.org> wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > The next question is, how do we keep it W=1 clean going forward? > > Most people don't use W=1 because it's too noisy, so it's a bit of a > catch-22. > > In i915, we enable a lot of W=1 warnings using subdir-ccflags-y in our > Makefile. For CI/developer use we also enable kernel-doc warnings by > default. > > Should we start enabling some of those warning flags in drm/Makefile to > to keep the entire subsystem warning free? I think that's a good idea. At least the documentation fixes I just merged could have been easily caught before submission. Maxime
On Thu, 24 Aug 2023, Jani Nikula wrote: > On Thu, 24 Aug 2023, Lee Jones <lee@kernel.org> wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > The next question is, how do we keep it W=1 clean going forward? My plan was to fix them all, then move each warning to W=0. Arnd recently submitted a set doing just that for a bunch of them. https://lore.kernel.org/all/20230811140327.3754597-1-arnd@kernel.org/ I like to think a bunch of this is built on top of my previous efforts. GPU is a particularly tricky though - the warnings seem to come in faster than I can squash them. Maybe the maintainers can find a way to test new patches on merge? > Most people don't use W=1 because it's too noisy, so it's a bit of a > catch-22. > > In i915, we enable a lot of W=1 warnings using subdir-ccflags-y in our > Makefile. For CI/developer use we also enable kernel-doc warnings by > default. > > Should we start enabling some of those warning flags in drm/Makefile to > to keep the entire subsystem warning free? That would we awesome! We'd just need buy-in.
On Thu, 24 Aug 2023, Lee Jones wrote: > On Thu, 24 Aug 2023, Jani Nikula wrote: > > > On Thu, 24 Aug 2023, Lee Jones <lee@kernel.org> wrote: > > > This set is part of a larger effort attempting to clean-up W=1 > > > kernel builds, which are currently overwhelmingly riddled with > > > niggly little warnings. > > > > The next question is, how do we keep it W=1 clean going forward? > > My plan was to fix them all, then move each warning to W=0. Some history: - Starting with v5.8-rc1: 18867 - 2020-07-01: 18089 - 2020-07-07: 17288 - 2020-07-17: 15762 - 2020-07-20: 15724 - 2020-07-23: 15116 - 2020-08-12: 15184 - 2020-10-19: 10909 - 2020-11-04: 9385 - 2021-01-04: 5478 - 2021-01-12 4749 - 2021-01-29 4911 - 2021-04-07 3594 - 2021-05-20 2938 - 2021-07-01 2587 - 2023-02-10 2587 - 2023-08-22 1650 > Arnd recently submitted a set doing just that for a bunch of them. > > https://lore.kernel.org/all/20230811140327.3754597-1-arnd@kernel.org/ > > I like to think a bunch of this is built on top of my previous efforts. > > GPU is a particularly tricky though - the warnings seem to come in faster > than I can squash them. Maybe the maintainers can find a way to test > new patches on merge? > > > Most people don't use W=1 because it's too noisy, so it's a bit of a > > catch-22. > > > > In i915, we enable a lot of W=1 warnings using subdir-ccflags-y in our > > Makefile. For CI/developer use we also enable kernel-doc warnings by > > default. > > > > Should we start enabling some of those warning flags in drm/Makefile to > > to keep the entire subsystem warning free? > > That would we awesome! We'd just need buy-in.
On Thu, 24 Aug 2023, Maxime Ripard wrote: > Hi, > > On Thu, Aug 24, 2023 at 10:59:54AM +0200, Maxime Ripard wrote: > > On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote: > > > This set is part of a larger effort attempting to clean-up W=1 > > > kernel builds, which are currently overwhelmingly riddled with > > > niggly little warnings. > > > > > > Cc: Alex Deucher <alexander.deucher@amd.com> > > > Cc: amd-gfx@lists.freedesktop.org > > > Cc: Ben Skeggs <bskeggs@redhat.com> > > > Cc: "Christian König" <christian.koenig@amd.com> > > > Cc: Daniel Vetter <daniel@ffwll.ch> > > > Cc: Danilo Krummrich <dakr@redhat.com> > > > Cc: David Airlie <airlied@gmail.com> > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: Fabio Estevam <festevam@gmail.com> > > > Cc: Gourav Samaiya <gsamaiya@nvidia.com> > > > Cc: Hawking Zhang <Hawking.Zhang@amd.com> > > > Cc: Hyun Kwon <hyun.kwon@xilinx.com> > > > Cc: Jerome Glisse <glisse@freedesktop.org> > > > Cc: Jonathan Hunter <jonathanh@nvidia.com> > > > Cc: Karol Herbst <kherbst@redhat.com> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > > > Cc: linaro-mm-sig@lists.linaro.org > > > Cc: linux-arm-kernel@lists.infradead.org > > > Cc: linux-media@vger.kernel.org > > > Cc: linux-tegra@vger.kernel.org > > > Cc: Luben Tuikov <luben.tuikov@amd.com> > > > Cc: Lyude Paul <lyude@redhat.com> > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > > Cc: "Maíra Canal" <mairacanal@riseup.net> > > > Cc: Mario Limonciello <mario.limonciello@amd.com> > > > Cc: Maxime Ripard <mripard@kernel.org> > > > Cc: Michal Simek <michal.simek@xilinx.com> > > > Cc: Mikko Perttunen <mperttunen@nvidia.com> > > > Cc: nouveau@lists.freedesktop.org > > > Cc: NXP Linux Team <linux-imx@nxp.com> > > > Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> > > > Cc: Pengutronix Kernel Team <kernel@pengutronix.de> > > > Cc: Philipp Zabel <p.zabel@pengutronix.de> > > > Cc: Sascha Hauer <s.hauer@pengutronix.de> > > > Cc: Shashank Sharma <shashank.sharma@amd.com> > > > Cc: Shawn Guo <shawnguo@kernel.org> > > > Cc: Stanley Yang <Stanley.Yang@amd.com> > > > Cc: Sumit Semwal <sumit.semwal@linaro.org> > > > Cc: Thierry Reding <thierry.reding@gmail.com> > > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > > > > > [...] > > > > Applied to drm/drm-misc (drm-misc-fixes). > > I got confused with b4 usage, but that wasn't actually applied. Only the > three patches I explicitly mentioned were, sorry for the confusion. :) Thanks Maxime.
On 8/24/23 08:07, Lee Jones wrote: > On Thu, 24 Aug 2023, Jani Nikula wrote: > >> On Thu, 24 Aug 2023, Lee Jones <lee@kernel.org> wrote: >>> This set is part of a larger effort attempting to clean-up W=1 >>> kernel builds, which are currently overwhelmingly riddled with >>> niggly little warnings. >> >> The next question is, how do we keep it W=1 clean going forward? > > My plan was to fix them all, then move each warning to W=0. > > Arnd recently submitted a set doing just that for a bunch of them. > > https://lore.kernel.org/all/20230811140327.3754597-1-arnd@kernel.org/ > > I like to think a bunch of this is built on top of my previous efforts. > > GPU is a particularly tricky though - the warnings seem to come in faster > than I can squash them. Maybe the maintainers can find a way to test > new patches on merge? I guess on that note, do you know if there is a way to run `scripts/kernel-doc` on patches instead of whole files? That would make much easier to block new kernel-doc issues from appearing. > >> Most people don't use W=1 because it's too noisy, so it's a bit of a >> catch-22. >> >> In i915, we enable a lot of W=1 warnings using subdir-ccflags-y in our >> Makefile. For CI/developer use we also enable kernel-doc warnings by >> default. >> >> Should we start enabling some of those warning flags in drm/Makefile to >> to keep the entire subsystem warning free? > > That would we awesome! We'd just need buy-in. >
On Thu, 24 Aug 2023, Hamza Mahfooz wrote: > > On 8/24/23 08:07, Lee Jones wrote: > > On Thu, 24 Aug 2023, Jani Nikula wrote: > > > > > On Thu, 24 Aug 2023, Lee Jones <lee@kernel.org> wrote: > > > > This set is part of a larger effort attempting to clean-up W=1 > > > > kernel builds, which are currently overwhelmingly riddled with > > > > niggly little warnings. > > > > > > The next question is, how do we keep it W=1 clean going forward? > > > > My plan was to fix them all, then move each warning to W=0. > > > > Arnd recently submitted a set doing just that for a bunch of them. > > > > https://lore.kernel.org/all/20230811140327.3754597-1-arnd@kernel.org/ > > > > I like to think a bunch of this is built on top of my previous efforts. > > > > GPU is a particularly tricky though - the warnings seem to come in faster > > than I can squash them. Maybe the maintainers can find a way to test > > new patches on merge? > > I guess on that note, do you know if there is a way to run > `scripts/kernel-doc` on patches instead of whole files? That would make > much easier to block new kernel-doc issues from appearing. Not off hand. When I run builds on patches I author, I run them twice concurrently. Once on the commit I'm basing on and once on the HEAD of my patchset. I then diff the two. So as long as the number of errors and warnings stay the same or reduce, we're golden. Perhaps the same method could be used with `kernel-doc`?
On 8/24/23 14:07, Lee Jones wrote: > On Thu, 24 Aug 2023, Jani Nikula wrote: >> On Thu, 24 Aug 2023, Lee Jones <lee@kernel.org> wrote: >>> This set is part of a larger effort attempting to clean-up W=1 >>> kernel builds, which are currently overwhelmingly riddled with >>> niggly little warnings. >> >> The next question is, how do we keep it W=1 clean going forward? > > My plan was to fix them all, then move each warning to W=0. > > Arnd recently submitted a set doing just that for a bunch of them. > > https://lore.kernel.org/all/20230811140327.3754597-1-arnd@kernel.org/ > > I like to think a bunch of this is built on top of my previous efforts. > > GPU is a particularly tricky though - the warnings seem to come in faster > than I can squash them. Maybe the maintainers can find a way to test > new patches on merge? One approach for this which has proved effective in Mesa and other projects is to make warnings fatal in CI which must pass for any changes to be merged. There is ongoing work toward introducing this for the DRM subsystem, using gitlab.freedesktop.org CI.
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Danilo Krummrich <dakr@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: Fabio Estevam <festevam@gmail.com> Cc: Gourav Samaiya <gsamaiya@nvidia.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Hyun Kwon <hyun.kwon@xilinx.com> Cc: Jerome Glisse <glisse@freedesktop.org> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: linaro-mm-sig@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-media@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: "Maíra Canal" <mairacanal@riseup.net> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Cc: nouveau@lists.freedesktop.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shashank Sharma <shashank.sharma@amd.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Stanley Yang <Stanley.Yang@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Lee Jones (20): drm/xlnx/zynqmp_disp: Use correct kerneldoc formatting in zynqmp_disp drm/nouveau/nvkm/subdev/acr/lsfw: Remove unused variable 'loc' drm/nouveau/nvkm/subdev/bios/init: Demote a bunch of kernel-doc abuses drm/nouveau/nvkm/subdev/volt/gk20a: Demote kerneldoc abuses drm/nouveau/nvkm/engine/gr/gf100: Demote kerneldoc abuse drm/nouveau/dispnv04/crtc: Demote kerneldoc abuses drm/radeon/radeon_ttm: Remove unused variable 'rbo' from radeon_bo_move() drm/amd/amdgpu/sdma_v6_0: Demote a bunch of half-completed function headers drm/tests/drm_kunit_helpers: Place correct function name in the comment header drm/scheduler/sched_main: Provide short description of missing param 'result' drm/amd/amdgpu/amdgpu_doorbell_mgr: Correct misdocumented param 'doorbell_index' drm/amd/amdgpu/amdgpu_device: Provide suitable description for param 'xcc_id' drm/tests/drm_kunit_helpers: Correct possible double-entry typo in 'ddrm_kunit_helper_acquire_ctx_alloc' drm/imx/ipuv3/imx-ldb: Increase buffer size to ensure all possible values can be stored drm/tegra/hub: Increase buffer size to ensure all possible values can be stored drm/drm_connector: Provide short description of param 'supported_colorspaces' drm/amd/amdgpu/amdgpu_ras: Increase buffer size to account for all possible values drm/drm_gpuva_mgr: Remove set but unused variable 'prev' drm/amd/amdgpu/amdgpu_sdma: Increase buffer size to account for all possible values drm/amd/amdgpu/imu_v11_0: Increase buffer size to ensure all possible values can be stored drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + .../gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 2 +- drivers/gpu/drm/amd/amdgpu/imu_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 8 +- drivers/gpu/drm/drm_connector.c | 2 + drivers/gpu/drm/drm_gpuva_mgr.c | 10 +- drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +- .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- .../gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c | 3 +- .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 136 +++++++++--------- .../gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 - drivers/gpu/drm/scheduler/sched_main.c | 1 + drivers/gpu/drm/tegra/hub.c | 2 +- drivers/gpu/drm/tests/drm_kunit_helpers.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +- 19 files changed, 96 insertions(+), 97 deletions(-)