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 cf
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 allo
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&#x
From: Arnd Bergmann
When the backlight support is disabled, the driver fails to build:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_sor_atomic_disable':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
nouveau_connector' has no member nam
From: Arnd Bergmann
A recent patch left an unused variable in place that needs to be
removed:
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c: In function 'hibmc_unload':
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c:252:35: error: unused variable
'priv' [-Werror=un
On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
>
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gp
On Fri, Jul 23, 2021 at 6:34 PM Karol Herbst wrote:
> On Fri, Jul 23, 2021 at 6:31 PM Randy Dunlap wrote:
> > On 7/23/21 8:15 AM, Karol Herbst wrote:
> > > On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap
> > > wrote:
> > >
> > > what's actually the use case of compiling with
> > > CONFIG_DRM_NOUVE
On Sat, Jul 24, 2021 at 12:47 AM Karol Herbst wrote:
>
> In the past this only led to compilation issues. Also the small amount of
> extra .text shouldn't really matter compared to the entire nouveau driver
> anyway.
>
> select DRM_TTM_HELPER
> - select BACKLIGHT_CLASS_DEVICE if DRM
On Sat, Jul 24, 2021 at 11:55 AM Karol Herbst wrote:
>
> On Sat, Jul 24, 2021 at 8:55 AM Arnd Bergmann wrote:
> >
> > On Sat, Jul 24, 2021 at 12:47 AM Karol Herbst wrote:
> > >
> > > In the past this only led to compilation issues. Also the small amount o
On Sat, Jul 24, 2021 at 2:52 PM Karol Herbst wrote:
>
> On Sat, Jul 24, 2021 at 2:10 PM Karol Herbst wrote:
> >
> > On Sat, Jul 24, 2021 at 1:56 PM Arnd Bergmann wrote:
> > >
> > > On Sat, Jul 24, 2021 at 11:55 AM Karol Herbst wrote:
> > >
> &g
On Sat, Jul 24, 2021 at 4:14 PM Karol Herbst wrote:
>
> we use the MXM_WMI in code. We also have to keep arm in mind and not
> break stuff there. So I will try to play around with your changes and
> see how that goes.
Ok, should find any randconfig build failures for arm, arm64 or x86 over the
we
From: Arnd Bergmann
Another missed dependency when SCM is a loadable module
and adreno is built-in:
drivers/gpu/drm/msm/adreno/adreno_gpu.o: In function `adreno_zap_shader_load':
adreno_gpu.c:(.text+0x1e8): undefined reference to `qcom_scm_is_available'
drivers/gpu/drm/msm/adreno/a5xx
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
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., CONFIG
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 id
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 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 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 d
fig
>
> Note: drivers/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
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
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).
> >
>
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/dr
On Mon, Aug 2, 2021 at 4:53 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Another missed dependency when SCM is a loadable module
> and adreno is built-in:
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.o: In function `adreno_zap_shader_load':
> adreno_gpu.c:(.tex
On Wed, Aug 4, 2021 at 6:36 AM Oleksij Rempel wrote:
>
> changes v4:
> - add vref-supply to adc@0
> - split gpio assignment for the mdio node
Hi Oleksij,
I've dropped the series from the soc patchwork, since this looks like
something that
should go through the i.MX tree. Please make it clear fro
On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
>
> playing around a little bit with this, I think the original "select
> BACKLIGHT_CLASS_DEVICE" is fine. Atm we kind of have this weird mix of
> drivers selecting and others depending on it. We could of course convert
> everything over to depend
On Wed, Aug 4, 2021 at 8:59 PM Karol Herbst wrote:
> On Wed, Aug 4, 2021 at 4:43 PM Karol Herbst wrote:
> > On Wed, Aug 4, 2021 at 4:19 PM Arnd Bergmann wrote:
> > > On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
> > > >
> > > > playing around a
On Thu, Aug 5, 2021 at 12:01 AM Karol Herbst wrote:
>
> On Wed, Aug 4, 2021 at 11:10 PM Arnd Bergmann wrote:
> >
> > On Wed, Aug 4, 2021 at 8:59 PM Karol Herbst wrote:
> > > On Wed, Aug 4, 2021 at 4:43 PM Karol Herbst wrote:
> > > > On Wed, Aug
On Mon, Aug 9, 2021 at 3:20 PM Jani Nikula wrote:
>
> On Sat, 24 Jul 2021, Arnd Bergmann wrote:
> > On Sat, Jul 24, 2021 at 4:14 PM Karol Herbst wrote:
> >>
> >> we use the MXM_WMI in code. We also have to keep arm in mind and not
> >> break stuff there.
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'
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 |
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
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 are
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
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: In
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 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/
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
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/cgroup.c:
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
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-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
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 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
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
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
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-wa
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 GC
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_securedispl
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 be
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 be
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
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 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:
&
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 be
SIZE - 2],
int 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, plea
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, th
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
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
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: e7
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,-Wimplici
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
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
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:
> >
> > WARNI
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: f
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
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
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]
timin
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
&
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
original
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/
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 func
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 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 ne
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/
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:
>
>
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 |
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-ov
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 valu
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
> > 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
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
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
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_n
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
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
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 st
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
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
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
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 wa
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
From: Arnd Bergmann
The driver fails to build when the KMS helpers are disabled:
ld.lld: error: undefined symbol: drm_gem_fb_get_obj
>>> referenced by drm_mipi_dbi.c
>>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive
>>> drivers/built-in.a
>&
From: Arnd Bergmann
The use of the old-style SET_RUNTIME_PM_OPS() and
SET_SYSTEM_SLEEP_PM_OPS() macros requires function definitions
to be hidden to avoid
drivers/gpu/drm/tegra/vic.c:326:12: error: 'vic_runtime_suspend' defined but
not used [-Werror=unused-function]
326 |
On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann wrote:
> Am 16.03.22 um 20:12 schrieb Thomas Zimmermann:
> >>
> >> Adding a dependency in all drivers that select DRM_MIPI_DBI avoids
> >> the problem for now, adding the dependency in DRM_MIPI_DBI as well
> >> should help make it easier to figure
On Thu, Mar 17, 2022 at 8:15 PM Thomas Zimmermann wrote:
> Am 16.03.22 um 21:59 schrieb Arnd Bergmann:
> > On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann
> > wrote:
> >
> > I was going for 'depends on' in the panel drivers because I saw the same
>
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already
On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
wrote:
>
> And I don't want somebody with a newer compiler version to not notice
> that he or she ended up using a c17 feature, just because _that_
> compiler supported it, and then other people get build errors because
> their compilers use gnu11 in
On Mon, Feb 28, 2022 at 12:04 AM Alex Elder wrote:
> On 2/27/22 3:52 PM, Arnd Bergmann wrote: From: Arnd Bergmann
> > I put the suggestion into patch form, based on what we discussed
> > in the thread. I only gave it minimal testing, but it would
> > be good to have it in
On Mon, Feb 28, 2022 at 1:14 AM John Stoffel wrote:
>
> On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu9
1 - 100 of 1611 matches
Mail list logo
