From: Arnd Bergmann
With the addition of the DMA fence, the host1x driver now fails to
build without the sync_file helper:
arm-linux-gnueabi-ld: drivers/gpu/host1x/fence.o: in function
`host1x_fence_create_fd':
fence.c:(.text+0x624): undefined reference to `sync_file_create'
Fixes
From: Arnd Bergmann
With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function
`drm_fb_helper_alloc_fbi':
(.text+0x10cc): undefined reference to `framebuffer_alloc'
Tighten the dependency so it is only allowed
From: Arnd Bergmann
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m
are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency
does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This
can however result in a build failure when cfb_fillrect
On Tue, Jun 8, 2021 at 6:49 PM Hans Verkuil wrote:
> On 08/06/2021 18:14, Arnd Bergmann wrote:
>
> Right now it is inherent to the driver. It is probably possible to drop
> support
> for video overlay devices if CONFIG_FB=n, but it is not something I have time
> for. It's
3 model B v1.2 with KASAN.
...
>
> Link:
> https://lore.kernel.org/r/4d0c8318-bad8-2be7-e292-fc8f70c19...@samsung.com
> Link:
> https://lore.kernel.org/linux-arm-kernel/20210607151740.moncryl5zv3ahq4s@gilmour
> Signed-off-by: Mark Rutland
> Reported-by: Marek Szyprowski
> Cc: Arnd Bergmann
Acked-by: Arnd Bergmann
On Mon, Jun 7, 2021 at 5:17 PM Maxime Ripard wrote:
> On Mon, Jun 07, 2021 at 03:57:41PM +0200, Arnd Bergmann wrote:
> > On Mon, Jun 7, 2021 at 3:39 PM Will Deacon wrote:
> > > On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
> > > > On Mon, Jun 07,
On Mon, Jun 7, 2021 at 3:39 PM Will Deacon wrote:
>
> [Adding VC4 folks -- please see the KASAN splat below!]
>
> Background here is that reducing ARCH_DMA_MINALIGN to 64 on arm64 (queued in
> -next) is causing vc4 to hang on Rpi3b due to a probable driver bug.
The great news for the patch that
> > On Wed, May 19, 2021 at 08:00:28PM +0800, songqiang wrote:
> > Signed-off-by: songqiang
> From: "Matthew Wilcox "
> > You need to explain:
> >
> > - Why you think this patch is needed
> > - Did you observe a problem at runtime?
> > - Is this the output from some checking tool?
> > - Why this
From: Arnd Bergmann
This is one of the last drivers with a global init_module() function
instead of the modern module_init() annotation. Convert it over.
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/matrox/matroxfb_base.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions
From: Arnd Bergmann
clang is a little overzealous with warning about a constant conversion
in an untaken branch of a ternary expression:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c:975:48: error: implicit conversion
from 'unsigned long long' to 'unsigned long' changes value from 50
From: Arnd Bergmann
gcc points out an invalid bit shift operation on 32-bit architectures
with 64-bit dma_addr_t:
drivers/gpu/drm/tegra/hub.c: In function 'tegra_shared_plane_atomic_update':
include/vdso/bits.h:7:40: error: left shift count >= width of type
[-Werror=shift-count-overflow]
From: Arnd Bergmann
The Kconfig dependency is incomplete since DRM_I915_GVT is a 'bool'
symbol that depends on the 'tristate' VFIO_MDEV. This allows a
configuration with VFIO_MDEV=m, DRM_I915_GVT=y and DRM_I915=y that
causes a link failure:
x86_64-linux-ld: drivers/gpu/drm/i915/gvt/gvt.o
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
>
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
>
On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
wrote:
> Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
>
> > soc_device_match() should only be used as a last resort, to identify
> > systems that cannot be identified otherwise. Typically this is used for
> > quirks, which
rivers/remoteproc seems to be special; commit c51e882cd711
> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains that
> there is a real dependency to DMA_CMA for it to work; leave that dependency
> in place and don't convert it to a soft dependency.
I do
On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand wrote:
> On 08.04.21 14:49, Linus Walleij wrote:
> > On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand wrote:
> >
> >>> This is something you could do using a hidden helper symbol like
> >>>
> >>> config DRMA_ASPEED_GFX
> >>> bool "Aspeed
On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij wrote:
>
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand wrote:
>
> > > This is something you could do using a hidden helper symbol like
> > >
> > > config DRMA_ASPEED_GFX
> > > bool "Aspeed display driver"
> > > select DRM_WANT_CMA
On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand wrote:
>
> On 08.04.21 13:44, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote:
> >>>
> >>> It is a somewhat awkward way to say "prevent this symbol from
> >>> be
On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote:
> >
> > It is a somewhat awkward way to say "prevent this symbol from
> > being =y if the dependency is =m".
>
> What would be the right thing to do in the case here then to achieve the
> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA
On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote:
> >>
> >> Random drivers should not override a user configuration of core knobs
> >> (e.g., CO
On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote:
>
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower limit
On Tue, Mar 30, 2021 at 10:41 AM Michal Koutný wrote:
>
> On Mon, Mar 22, 2021 at 05:02:44PM +0100, Arnd Bergmann
> wrote:
> > I'm not sure what is expected to happen for such a configuration,
> > presumably these functions are never calls in that case.
> Yes, the fun
lane_count);
bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count);
This obviously needs a good explanation in the code and the changelog text,
which I don't have, but if the above is what you had in mind, please take that
and add Reported-by/Tested-by: A
From: Arnd Bergmann
When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:
drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array
bounds
On Wed, Mar 24, 2021 at 3:20 PM Joe Perches wrote:
>
> On Wed, 2021-03-24 at 13:17 +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When CONFIG_OF is disabled, building with 'make W=1' produces warnings
> > about out of bounds array access:
> &g
From: Arnd Bergmann
A previous fix I did left a rather complicated loop in
amdgpu_securedisplay_debugfs_write() for what could be expressed in a
simple sprintf, as Rasmus pointed out.
This drops the leading 0x for each byte, but is otherwise
much nicer.
Suggested-by: Rasmus Villemoes
Signed
On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes
wrote:
> On 23/03/2021 14.04, Arnd Bergmann wrote:
> > if (securedisplay_cmd->status ==
> > TA_SECUREDISPLAY_STATUS__SUCCESS) {
> > + int pos = 0;
> >
From: Arnd Bergmann
When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:
drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array
bounds
From: Arnd Bergmann
When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:
drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array
bounds
From: Arnd Bergmann
gcc warns about an sprintf() that uses the same buffer as source
and destination, which is undefined behavior in C99:
drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c: In function
'amdgpu_securedisplay_debugfs_write':
drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c:141:6
On Mon, Mar 22, 2021 at 11:09 PM Martin Sebor wrote:
> On 3/22/21 2:29 PM, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> >
> > I.e. the real workaround might be to turn off the
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
>
> In
On Mon, Mar 22, 2021 at 9:29 PM Ingo Molnar wrote:
> * Arnd Bergmann wrote:
> > From: Arnd Bergmann
> This is indeed rather ugly - and the other patch that removes a debug
> check seems counterproductive as well.
>
> Do we know how many genuine bugs -Wstringop-overread
From: Arnd Bergmann
An old patch added a 'return' statement after each BUG() in this driver,
which was necessary at the time, but has become redundant after the BUG()
definition was updated to handle this properly.
gcc-11 now warns about one such instance, where the 'return' statement
From: Arnd Bergmann
With gcc-11, we get a warning about code that looks correct
but badly indented:
drivers/video/backlight/jornada720_bl.c: In function ‘jornada_bl_update_status’:
drivers/video/backlight/jornada720_bl.c:66:11: error: this ‘else’ clause does
not guard... [-Werror=misleading
From: Arnd Bergmann
gcc-11 warns that intel_dp_check_mst_status() has a local array of
fourteen bytes and passes the last four bytes into a function that
expects a six-byte array:
drivers/gpu/drm/i915/display/intel_dp.c: In function
‘intel_dp_check_mst_status’:
drivers/gpu/drm/i915/display
From: Arnd Bergmann
gcc-11 warns about what appears to be an out-of-range array access:
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3108:3:
drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’ reading
16
From: Arnd Bergmann
gcc-11 warns about an strnlen with a length larger than the size of the
passed buffer:
drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_nvme_info_show':
drivers/scsi/lpfc/lpfc_attr.c:518:25: error: 'strnlen' specified bound 4095
exceeds source size 24 [-Werror=stringop
From: Arnd Bergmann
gcc-11 notices that the fields as defined in the ass_req_format
structure do not match the actual use of that structure:
cc1: error: writing 4 bytes into a region of size between 18446744073709551613
and 2 [-Werror=stringop-overflow=]
drivers/net/wireless/atmel/atmel.c:2884
From: Arnd Bergmann
gcc warns that accessing a pointer based on a numeric constant may
be an offset into a NULL pointer, and would therefore has zero
accessible bytes:
arch/arm/common/sharpsl_param.c: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.c:43:9: error: ‘memcpy
From: Arnd Bergmann
When cgroups are enabled, but every single subsystem is turned off,
CGROUP_SUBSYS_COUNT is zero, and the cgrp->subsys[] array has no
members.
gcc-11 points out that this leads to an invalid access in any function
that might access this array:
kernel/cgroup/cgrou
From: Arnd Bergmann
gcc-11 warns that the size of the link name is longer than the di_fname
field:
fs/qnx4/dir.c: In function ‘qnx4_readdir’:
fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds source size 16
[-Werror=stringop-overread]
51 | size
From: Arnd Bergmann
gcc-11 with the kernel address sanitizer prints a warning for this
driver:
In function 'ath11k_peer_assoc_h_vht',
inlined from 'ath11k_peer_assoc_prepare' at
drivers/net/wireless/ath/ath11k/mac.c:1632:2:
drivers/net/wireless/ath/ath11k/mac.c:1164:13: error
From: Arnd Bergmann
gcc-11 introdces a harmless warning for cap_inode_getsecurity:
security/commoncap.c: In function ‘cap_inode_getsecurity’:
security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region of
size 0 [-Werror=stringop-overread]
440
From: Arnd Bergmann
gcc-11 warns about using string operations on pointers that are
defined at compile time as offsets from a NULL pointer. Unfortunately
that also happens on the result of fix_to_virt(), which is a
compile-time constant for a constantn input:
arch/x86/kernel/tboot.c
From: Arnd Bergmann
gcc gets confused by the comparison of a pointer to an integer listeral,
with the assumption that this is an offset from a NULL pointer and that
dereferencing it is invalid:
In file included from arch/x86/boot/compressed/misc.c:18:
In function ‘parse_elf’,
inlined from
From: Arnd Bergmann
The coming gcc release introduces a new warning for string operations
reading beyond the end of a fixed-length object. After testing
randconfig kernels for a while, think I have patches for any such
warnings that came up on x86, arm and arm64.
Most of these warnings
From: Arnd Bergmann
clang points out that the %hu format string does not match the type
of the variables here:
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:263:7: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat
From: Arnd Bergmann
Building with W=1 shows a few warnings for an empty macro:
drivers/gpu/drm/qxl/qxl_drv.c: In function 'qxl_pci_probe':
drivers/gpu/drm/qxl/qxl_drv.c:131:50: error: suggest braces around empty body
in an 'if' statement [-Werror=empty-body]
131 | vga_put
From: Arnd Bergmann
Building with 'make W=1' shows a few harmless warnings:
drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function 'omapfb_calc_addr':
drivers/video/fbdev/omap2/omapfb/omapfb-main.c:823:56: error: suggest braces
around empty body in an 'if' statement [-Werror=empty-body
On Tue, Mar 9, 2021 at 7:34 PM Christian König wrote:
> Am 09.03.21 um 18:59 schrieb Alex Deucher:
>
> There has been quite some effort for this already for generic PASID
> interface etc.. But it looks like that effort is stalled by now.
>
> Anyway at least I'm perfectly fine to have the IOMMUv2
On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote:
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd
On Mon, Mar 8, 2021 at 9:12 PM Christian König
wrote:
> Am 08.03.21 um 21:02 schrieb Felix Kuehling:
> > Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann:
> > I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid
> > it, because it is only really need
On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote:
>
> Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
> > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling
> > wrote:
> >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we
> >>
On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote:
>
> The driver build should work without IOMMUv2. In amdkfd/Makefile, we
> have this condition:
>
> ifneq ($(CONFIG_AMD_IOMMU_V2),)
> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
> endif
>
> In amdkfd/kfd_iommu.h we define inline stubs of the
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd
On Thu, Feb 25, 2021 at 10:34 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
> return parse_edid_cea(aconnector, edid_ext, EDID_LENGTH, vsdb_info) ? i :
> -ENODEV;
>
> would suffice, but the patch is still fine as is.
Right, I did not want to change more than necessary here, and the
On Thu, Feb 25, 2021 at 3:33 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> The new display synchronization code caused a regression
> on all 32-bit architectures:
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
> >>> referenced by dce_clock_source.c
&
From: Arnd Bergmann
clang points out that the new logic uses an always-uninitialized
array index:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9810:38: warning:
variable 'i' is uninitialized when used here [-Wuninitialized]
timing = >detailed_timing
From: Arnd Bergmann
The new display synchronization code caused a regression
on all 32-bit architectures:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by dce_clock_source.c
>>>
>>> gpu/drm/amd/display/dc/dce/dce_clock_source.o:(ge
From: Arnd Bergmann
I noticed a warning from 'nm' when CONFIG_TRIM_UNUSED_KSYMS is set
and IS_REACHABLE(CONFIG_AGP) is false:
drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.o: no symbols
I later found this is completely harmless and we should find a way
to suppress the warning, but at that point
On Mon, Jan 25, 2021 at 1:51 PM Chen, Guchun wrote:
>
> [AMD Public Use]
>
> Hi Arnd Bergmann,
>
> Thanks for your patch. This link error during compile has been fixed by below
> commit and been submitted to drm-next branch already.
>
> 5da047444e82 drm/amd/display
On Mon, Jan 25, 2021 at 1:33 PM Chris Wilson wrote:
>
> Quoting Arnd Bergmann (2021-01-25 12:26:44)
> > From: Arnd Bergmann
> >
> > CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
> > to honor its dependencies:
> >
> > W
From: Arnd Bergmann
After all users of the 'dm' warnings got hidden in an #ifdef,
the compiler started warning about it being unused:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33: error:
unused variable 'dm' [-Werror,-Wunused-variable]
Add another such #ifdef.
Fixes
From: Arnd Bergmann
CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
to honor its dependencies:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TE
From: Arnd Bergmann
The x86-specific wbinvd_on_all_cpus() function is exported
through asm/smp.h, causing a build failure in the i915 driver
when SMP is disabled:
drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of function
'wbinvd_on_all_cpus' [-Werror,-Wimplicit-function
From: Arnd Bergmann
clang warns about the -mhard-float command line arguments
on architectures that do not support this:
clang: error: argument unused during compilation: '-mhard-float'
[-Werror,-Wunused-command-line-argument]
Move this into the gcc-specific arguments.
Fixes: e77165bf7b02
From: Arnd Bergmann
The open-coded 64-bit division causes a link error on 32-bit
machines:
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Use the div_s64() to perfo
From: Arnd Bergmann
The zte zx platform is getting removed, so this driver is no
longer needed.
Cc: Jun Nie
Cc: Shawn Guo
Link:
https://lore.kernel.org/linux-arm-kernel/20210120124812.2800027-1-a...@kernel.org/T/
Signed-off-by: Arnd Bergmann
---
.../devicetree/bindings/display/zte,vou.txt
From: Arnd Bergmann
When LLCC support is in a loadable module, the adreno support
cannot be built-in:
aarch64-linux-ld: drivers/gpu/drm/msm/adreno/a6xx_gpu.o: in function
`a6xx_gpu_init':
a6xx_gpu.c:(.text+0xe0): undefined reference to `llcc_slice_getd'
a6xx_gpu.c:(.text+0xe0): relocation
From: Arnd Bergmann
Some of the newly added code is hidden inside of #ifdef
blocks, but one variable is unused when debugfs is disabled:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8370:8: error:
unused variable 'configure_crc' [-Werror,-Wunused-variable]
Change the #ifdef
From: Arnd Bergmann
Randconfig builds on 32-bit machines show lots of warnings for
the i915 driver for passing a 32-bit value into __const_hweight64():
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2584:9: error: shift count >=
width of type [-Werror,-Wshift-count-overflow]
ret
On Wed, Dec 30, 2020 at 4:56 PM Chris Wilson wrote:
>
> Quoting Arnd Bergmann (2020-12-30 15:39:14)
> > From: Arnd Bergmann
> >
> > Randconfig builds on 32-bit machines show lots of warnings for
> > the i915 driver for incorrect bit masks like:
>
> mask is
From: Arnd Bergmann
Randconfig builds on 32-bit machines show lots of warnings for
the i915 driver for incorrect bit masks like:
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2584:9: error: shift count >=
width of type [-Werror,-Wshift-count-overflow]
return hweight64(VDBOX_MASK(
On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann wrote:
> >
> > On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> Hmm...no warnings for me with t
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann wrote:
> >
> > Right, looking at my latest randconfig logs, I see the same problem on x86
> > builds with clang as well, though I'm not e
On Mon, Dec 7, 2020 at 9:50 PM Christian König wrote:
> Am 07.12.20 um 21:47 schrieb Alex Deucher:
> > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote:
> >> From: Arnd Bergmann
> >>
> >> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
&g
From: Arnd Bergmann
ttm_pool_type_count() is not used when debugfs is disabled:
drivers/gpu/drm/ttm/ttm_pool.c:243:21: error: unused function
'ttm_pool_type_count' [-Werror,-Wunused-function]
static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
Move the definition into the #ifdef
From: Arnd Bergmann
Without debugfs, the compiler notices one function that is not used at
all:
drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:123:12: error: unused
function 'amdgpu_is_fw_attestation_supported' [-Werror,-Wunused-function]
In fact the static const
From: Arnd Bergmann
As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
arm64, merging it into DRM_AMD_DC means that the top-level symbol
is now x86-only as well.
Compilation fails on arm64 with clang-12 with
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c
From: Arnd Bergmann
The iommu pgtable support is only available when IOMMU support
is built into the kernel:
WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE
Depends on [n]: IOMMU_SUPPORT [=n]
Selected by [y]:
- DRM_MSM [=y] && HAS_IOMEM [=y] && DRM [=y] &
From: Arnd Bergmann
There is still a warning when CONFIG_DEBUG_FS is disabled:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error:
'amdgpu_ras_debugfs_create_ctrl_node' defined but not used
[-Werror=unused-function]
1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct
From: Arnd Bergmann
gcc warns about an out-of-bounds access when the using nonzero
values for 'plane_id' on kmb->plane_status:
drivers/gpu/drm/kmb/kmb_plane.c: In function 'kmb_plane_atomic_disable':
drivers/gpu/drm/kmb/kmb_plane.c:128:20: warning: array subscript 3 is above
array bou
On Wed, Nov 18, 2020 at 10:13 AM Maxime Ripard wrote:
>
> Hi Arnd, Olof,
>
> Here's the PR for the MBUS rework we discussed in the last couple of
> weeks, for what will become 5.11.
>
> As Arnd suggested, this is based on a PR sent to drm-misc-fixes to merge
> the initial fix for a probe error in
in softirq
> 2 maps in interrupt
>
> So a total of 16 is sufficient and probably overestimated.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Arnd Bergmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Oct 27, 2020 at 10:54 AM Patrik Jakobsson
wrote:
> On Tue, Oct 27, 2020 at 10:33 AM Daniel Vetter wrote:
> > On Mon, Oct 26, 2020 at 08:41:04PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > gcc -Wextra notices that one of
On Tue, Oct 27, 2020 at 4:31 PM Jyri Sarha wrote:
> On 26/10/2020 21:41, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The -Wmissing-field-initializer warning when building with W=2
> > turns into an error because tilcdc is built with -Werror:
> >
> >
From: Arnd Bergmann
Building with 'make W=1' produces countless warnings like
amdgpu/../include/vega10_ip_offset.h:276:51: warning: initialized field
overwritten [-Woverride-init]
Shut these up by disabling the particular warning in the
amdgpu driver.
Signed-off-by: Arnd Bergmann
From: Arnd Bergmann
gcc -Wextra warns about an incorrect prototype causing multiple
mismatched enums:
display/dc/gpio/gpio_service.c: In function 'dal_gpio_service_create':
display/dc/gpio/gpio_service.c:70:50: warning: implicit conversion from 'enum
dce_environment' to 'enum dce_version
From: Arnd Bergmann
gcc -Wextra warns about a function taking an enum argument
being called with a bool:
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function
'apply_degamma_for_user_regamma':
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1617:29
From: Arnd Bergmann
A conversion from 'bool' to 'enum odm_combine_mode' was incomplete,
and gcc warns about this with many instances of
display/dc/dml/dcn20/display_mode_vba_20.c:3899:44: warning: implicit
conversion from 'enum ' to 'enum
odm_combine_mode' [-Wenum-conversion]
3899
From: Arnd Bergmann
core_link_write_dpcd() returns enum dc_status, not ddc_result:
display/dc/core/dc_link_dp.c: In function 'dp_set_panel_mode':
display/dc/core/dc_link_dp.c:4237:11: warning: implicit conversion from 'enum
dc_status' to 'enum ddc_result'
[-Wenum-conversion]
Avoid the warning
From: Arnd Bergmann
There is one harmless duplicate initialization that causes a warning
with 'make W=1':
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:122:19: warning: initialized
field overwritten [-Woverride-init]
122 | .max_linewidth = 4096,
| ^~~~
drivers/gpu
From: Arnd Bergmann
gcc -Wextra notices that one of the fields in psbfb_roll_ops has two
initializers:
drivers/gpu/drm/gma500/framebuffer.c:185:20: warning: initialized field
overwritten [-Woverride-init]
Open-code this instead, leaving out the extraneous initializers for
.fb_pan_display
From: Arnd Bergmann
clang warns about functions returning a 'const int' result:
drivers/gpu/drm/imx/imx-tve.c:487:8: warning: type qualifiers ignored on
function return type [-Wignored-qualifiers]
Remove the extraneous 'const' qualifier here. I would guess that the
function was intended
From: Arnd Bergmann
The -Wmissing-field-initializer warning when building with W=2
turns into an error because tilcdc is built with -Werror:
drm/tilcdc/tilcdc_drv.c:431:33: error: missing field 'data' initializer
[-Werror,-Wmissing-field-initializers] { "regs", tilcdc_regs_show
From: Arnd Bergmann
The open-coded list_for_each_entry() causes a harmless warning:
drivers/video/fbdev/matrox/matroxfb_base.c: In function
'matroxfb_register_driver':
include/linux/kernel.h:856:3: warning: array subscript -98 is outside array
bounds of 'struct list_head[1]' [-Warray-bounds
On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote:
>
> Hi Daniel/Arnd.
>
> On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> > > The fbdev code uses compat_alloc_user_space in a fe
of
modifications.
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/sbuslib.c | 95 ++-
1 file changed, 70 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c
index f728db9bcff8..da28c279a54b 100644
601 - 700 of 1588 matches
Mail list logo
