mbox series

[(set,1),00/20] Rid W=1 warnings from GPU

Message ID 20230824073710.2677348-1-lee@kernel.org
Headers show
Series Rid W=1 warnings from GPU | expand

Message

Lee Jones Aug. 24, 2023, 7:36 a.m. UTC
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(-)

Comments

Lee Jones Aug. 24, 2023, 12:07 p.m. UTC | #1
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.
Lee Jones Aug. 24, 2023, 12:08 p.m. UTC | #2
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.
Lee Jones Aug. 24, 2023, 12:10 p.m. UTC | #3
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.
Lee Jones Aug. 24, 2023, 12:24 p.m. UTC | #4
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`?