On Thu, Oct 2, 2025, at 15:53, Mathieu Desnoyers wrote:
> On 2025-10-02 04:24, Greg KH wrote:
>> On Thu, Oct 02, 2025 at 05:12:01PM +0900, Byungchul Park wrote:
>>> llist_head and llist_node can be used by some other header files. For
>>> example, dept for tracking dependencies uses llist in its h
On Tue, Sep 9, 2025, at 15:19, Thomas Zimmermann wrote:
> Several fbdev drivers select FB_MODE_HELPER in the Kconfig. The
> setting controls some helper fucntions and has no meaning to the
> user. Make it an internal option.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
On Wed, Sep 10, 2025, at 11:28, Thomas Zimmermann wrote:
> Am 09.09.25 um 19:29 schrieb Arnd Bergmann:
>> On Tue, Sep 9, 2025, at 15:19, Thomas Zimmermann wrote:
>>
>> Is there any reason I missed why enabling FB_TILEBLITTING is
>> useful if you don't use one of
On Thu, Sep 11, 2025, at 22:24, Nathan Chancellor wrote:
>
> Cc: sta...@vger.kernel.org
> Link:
> https://github.com/llvm/llvm-project/commit/055bfc027141bbfafd51fb43f5ab81ba3b480649
>
> [1]
> Link: https://llvm.org/pr143908 [2]
> Signed-off-by: Nathan Chancellor
Acked-by: Arnd Bergmann
On Tue, Sep 9, 2025, at 15:19, Thomas Zimmermann wrote:
> The option CONFIG_FB_TILEBLITTING is controlled by the user. Selecting
> it from drivers can lead to cyclic dependencies within the config. In
> fbcon, there's special handling for tile blitting, which currently
> cannot be disabled without
On Thu, Aug 7, 2025, at 10:09, Dmitry Baryshkov wrote:
> On Thu, Aug 07, 2025 at 09:19:48AM +0200, Arnd Bergmann wrote:
>>
>> The bug is real, but the suggestion from clang to set it to NULL is
>> unfortunately just as harmful as dereferencing a NULL pointer is little
>>
From: Arnd Bergmann
clang-21 points out a variable that is conditionally initialized
but then dereferenced:
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1138:6: error: variable 'crtc_state'
is used uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-
From: Arnd Bergmann
My previous patch ended up causing a regression for the
DRM_IOCTL_NOUVEAU_NVIF ioctl. The intention of my patch was to only
pass ioctl commands that have the correct dir/type/nr bits into the
nouveau_abi16_ioctl() function.
This turned out to be too strict, as userspace does
On Tue, Jul 22, 2025, at 12:29, Chris Bainbridge wrote:
> On Mon, Jul 21, 2025 at 08:22:48AM -0400, Satadru Pramanik wrote:
>> Hello all,
>>
>> I suspect this commit in 6.16-rc7 has broken acceleration with Mesa's
>> nouveau drivers on my machine.
>>
>> glxinfo -B reports that I'm using llvmpipe.
tl(6, DRM_IOCTL_GEM_CLOSE, 0x7ffc5a255060) = 0
> < 10221 ioctl(6, DRM_IOCTL_GEM_CLOSE, 0x7ffc5a255060) = 0
> < 10221 ioctl(6, DRM_IOCTL_GEM_CLOSE, 0x7ffc5a255060) = 0
> < 10221 ioctl(6, DRM_IOCTL_GEM_CLOSE, 0x7ffc5a255060) = 0
> < 10221 ioctl(6, DRM_IOCTL_NOUVEAU_C
On Mon, Jul 21, 2025, at 14:22, Satadru Pramanik wrote:
> Hello all,
>
> I suspect this commit in 6.16-rc7 has broken acceleration with Mesa's
> nouveau drivers on my machine.
>
> glxinfo -B reports that I'm using llvmpipe.
Thanks for the report! Can you run the failing command with
'strace -f -o
On Mon, Jul 14, 2025, at 16:59, Limonciello, Mario wrote:
> On 7/14/25 3:16 AM, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> When power management is not enabled in the kernel build, the newly
>> added hibernation changes cause a link failure:
>>
>>
From: Arnd Bergmann
When power management is not enabled in the kernel build, the newly
added hibernation changes cause a link failure:
arm-linux-gnueabi-ld: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o: in function
`amdgpu_pmops_thaw':
amdgpu_drv.c:(.text+0x1514): undefined referen
On Fri, Jul 11, 2025, at 19:41, Danilo Krummrich wrote:
> On Fri Jul 11, 2025 at 9:24 AM CEST, Arnd Bergmann wrote:
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index 1527b801f013..506eeb44f0d4 100644
>> --
From: Arnd Bergmann
nouveau_drm_ioctl() only checks the _IOC_NR() bits in the DRM_NOUVEAU_NVIF
command, but ignores the type and direction bits, so any command with
'7' in the low eight bits gets passed into nouveau_abi16_ioctl() instead
of drm_ioctl().
Check for all the bits excep
oked, resulting in a build break when KMS is disabled. Add some
> additional ifdef to fix that.
>
> Reported-by: Arnd Bergmann
> Fixes: 98290b0a7d60 ("drm/msm: make it possible to disable KMS-related code.")
> Signed-off-by: Rob Clark
Thanks for the fix!
Tested-by: Arnd Bergmann
From: Arnd Bergmann
Commit dc2139c0aa32 ("leds: backlight trigger: Replace fb events with a
dedicated function call") removed the FB_EVENT_BLANK notifier, and now
the only remaining user of the FB notifier is the metronomefb driver on
the PXA/AM200EPD board.
This was introduced
From: Arnd Bergmann
This driver has not worked correctly for many years, and the only in-tree
reference to it is going away as well, so remove the driver now.
Signed-off-by: Arnd Bergmann
---
Documentation/fb/index.rst| 1 -
Documentation/fb/metronomefb.rst | 38 --
drivers/video
From: Arnd Bergmann
The driver started using readl/writel, which are defined in linux/io.h,
so this needs to be included here:
drivers/gpu/drm/msm/dp/dp_panel.c:33:9: error: call to undeclared function
'readl_relaxed'; ISO C99 and later do not support implicit function
de
From: Arnd Bergmann
When KMSAN is enabled, this function causes has a rather excessive stack usage:
drivers/gpu/drm/i915/display/skl_watermark.c:2977:1: error: stack frame size
(1432) exceeds limit (1408) in 'skl_compute_wm' [-Werror,-Wframe-larger-than]
This is apparently all cau
From: Arnd Bergmann
The igt_vma_pin1() function has a rather high stack usage, which gets
in the way of reducing the default warning limit:
In file included from drivers/gpu/drm/i915/i915_vma.c:2285:
drivers/gpu/drm/i915/selftests/i915_vma.c:257:12: error: stack frame size
(1288) exceeds limit
From: Arnd Bergmann
An earlier patch fixed a build failure with clang, but I still see the
same problem with some configurations using gcc:
drivers/gpu/drm/i915/i915_pmu.c: In function 'config_mask':
include/linux/compiler_types.h:568:38: error: call to
'__compiletime_assert_462
On Thu, Jun 12, 2025, at 16:37, Tomi Valkeinen wrote:
> On 12/06/2025 15:40, Arnd Bergmann wrote:
> static u16 DISPC_OVL_BASE(enum omap_plane_id plane)
> {
> static const u16 bases[] = {0x0080, 0x00BC, 0x014C, 0x0300, 0x0500};
> return bases[plane];
> }
>
> In a
On Thu, Jun 12, 2025, at 09:58, Tomi Valkeinen wrote:
> On 10/06/2025 12:27, Arnd Bergmann wrote:
>>
>> -static void dispc_restore_context(struct dispc_device *dispc)
>> +static noinline_for_stack void dispc_restore_context(struct dispc_device
>> *dispc)
>> {
&
From: Arnd Bergmann
The use of vararg function pointers combined with a huge number of
arguments causes some configurations to exceed the stack size warning
limit:
drivers/staging/fbtft/fbtft-core.c:863:12: error: stack frame size (1512)
exceeds limit (1280) in
On Tue, Jun 10, 2025, at 13:23, Arnd Bergmann wrote:
> {
> struct device *dev = par->info->device;
> - int buf[64], count, index, i, j, ret;
> + u32 buf[64], count, index, i, j, ret;
> u32 *values;
> u32 val;
>
I was too quick to update thi
On Tue, Jun 10, 2025, at 12:26, Andy Shevchenko wrote:
> On Tue, Jun 10, 2025 at 11:24:38AM +0200, Arnd Bergmann wrote:
>> Move the varargs handling into a separate noinline function so each
>> individual function stays below the limit. A better approach might be to
>> replace
From: Arnd Bergmann
test_prepare_array() is one of the functions that uses more than
a kilobyte of stack on 64-bit machines, though it stays under
the usual warning limit of 2KB:
drivers/gpu/drm/tests/drm_exec_test.c: In function 'test_prepare_array':
drivers/gpu/drm/tests/drm_exec_te
From: Arnd Bergmann
Clang inlines radeon_cs_parser_relocs() into radeon_cs_ioctl(), and
since both of these use a lot of stack space, the sum of them can
make it exceed a limit of 1280 bytes:
drivers/gpu/drm/radeon/radeon_cs.c:669:5: error: stack frame size (1328)
exceeds limit (1280) in
From: Arnd Bergmann
The thread sanitizer makes the stack usage explode from extra variable
spills in dispc_runtime_resume:
drivers/gpu/drm/omapdrm/dss/dispc.c:4735:27: error: stack frame size (1824)
exceeds limit (1280) in 'dispc_runtime_resume' [-Werror,-Wframe-larger-than]
I
From: Arnd Bergmann
The use of vararg function pointers combined with a huge number of
arguments causes some configurations to exceed the stack size warning
limit:
drivers/staging/fbtft/fbtft-core.c:863:12: error: stack frame size (1512)
exceeds limit (1280) in
On Wed, May 28, 2025, at 12:31, Andy Shevchenko wrote:
> On Wed, May 28, 2025 at 03:17:03AM -0700, Christopher Snowhill wrote:
>> On Wed May 28, 2025 at 3:03 AM PDT, Arnd Bergmann wrote:
>> > On Wed, May 28, 2025, at 11:34, Andy Shevchenko wrote:
>> >> On Tue, Ma
On Wed, May 28, 2025, at 11:34, Andy Shevchenko wrote:
> On Tue, May 27, 2025 at 03:55:46PM -0500, Lucas De Marchi wrote:
>> On Fri, May 23, 2025 at 02:10:46PM +0200, Arnd Bergmann wrote:
>
> ...
>
>> > + depends on INTEL_PLATFORM_DEVICES || !(X86 && ACPI)
>&
From: Arnd Bergmann
The newly added driver uses the DSC helper module, but does not
select its Kconfig symbol, so configurations are possible that
cause a link failure:
ERROR: modpost: "drm_dsc_pps_payload_pack"
[drivers/gpu/drm/panel/panel-novatek-nt37801.ko] undefined!
Fixes: 4f
From: Arnd Bergmann
The XE driver can be built with or without VSEC support, but fails to link as
built-in if vsec is in a loadable module:
x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init':
(.text+0x1e83e16): undefined reference to `intel_vsec_register'
The normal fix for this
On Fri, May 9, 2025, at 05:15, Andrew Ballance wrote:
> +
> +#define define_rust_pio_read_helper(name, type) \
> + type rust_helper_##name(unsigned long port) \
> + { \
> + return name(port); \
> + }
> +
> +#defi
On Fri, May 9, 2025, at 05:15, Andrew Ballance wrote:
> currently the rust `Io` type maps to the c read{b, w, l, q}/write{b, w, l, q}
> functions and have no support for port io.this is a problem for pci::Bar
> because the pointer returned by pci_iomap is expected to accessed with
> the ioread/iowr
On Fri, May 9, 2025, at 05:15, Andrew Ballance wrote:
> +}
> +#[cfg(not(CONFIG_GENERIC_IOMAP))]
> +mod io_backend {
> +// for everyone who does not use generic iomap
> +// except for alpha and parisc, neither of which has a rust compiler,
> +// ioread/iowrite is defined in `include/asm
On Fri, May 9, 2025, at 05:15, Andrew Ballance wrote:
> From: Fiona Behrens
>
> Move the non arch specific PIO size to linux/io.h.
>
> This allows rust to access `PIO_OFFSET`, `PIO_MASK` and
> `PIO_RESERVED`. This is required to implement `IO_COND` in rust.
>
> Signed-off-by: Fiona Behrens
> Sign
On Fri, May 9, 2025, at 05:15, Andrew Ballance wrote:
> +
> +define_rust_mmio_read_helper(readb, u8);
> +define_rust_mmio_read_helper(readw, u16);
> +define_rust_mmio_read_helper(readl, u32);
This makes it harder to grep for the definitions when trying
to follow the code flow. Can you find a way t
From: Arnd Bergmann
The device core dumps are copied in 1.5GB chunks, which leads to a
link-time error on 32-bit builds because of the 64-bit division not
getting trivially turned into mask and shift operations:
ERROR: modpost: "__moddi3" [drivers/gpu/drm/xe/xe.ko] undefined!
On top
From: Arnd Bergmann
The newly added driver calls drm_client_setup(), but that is not
always built in:
x86_64-linux-ld: vmlinux.o: in function `st7571_probe':
st7571-i2c.c:(.text+0x7b7119): undefined reference to `drm_client_setup'
Select the appropriate Kconfig symbol.
Fixes: 4b
On Thu, Apr 24, 2025, at 13:41, Boris Brezillon wrote:
> On Thu, 24 Apr 2025 13:25:47 +0200
>> +#ifdef CONFIG_DEBUG_FS
>> bo->debugfs.flags = usage_flags |
>> PANTHOR_DEBUGFS_GEM_USAGE_FLAG_INITIALIZED;
>> -}
>> -
>> -#else
>> -void panthor_gem_debugfs_set_usage_flags(struct panthor_gem_objec
From: Arnd Bergmann
When debugfs is disabled, including panthor_gem.h causes warnings
about a non-static global function defined in a header:
In file included from drivers/gpu/drm/panthor/panthor_drv.c:30:
drivers/gpu/drm/panthor/panthor_gem.h:222:6: error: no previous prototype for
From: Arnd Bergmann
It turns out that there are no platforms that have PCI but don't have an MMU,
so adding a Kconfig dependency on CONFIG_PCI simplifies build testing kernels
for those platforms a lot, and avoids a lot of inadvertent build regressions.
Add a dependency for CONFIG_PC
From: Arnd Bergmann
DRM_DISPLAY_DP_AUX_BUS cannot be selected when CONFIG_OF is disabled:
WARNING: unmet direct dependencies detected for DRM_DISPLAY_DP_AUX_BUS
Depends on [n]: HAS_IOMEM [=y] && DRM [=y] && OF [=n]
Selected by [y]:
- DRM_ROCKCHIP [=y] && H
From: Arnd Bergmann
goa_even_valid is only initialized in one branch but not the other:
drivers/gpu/drm/panel/panel-himax-hx8279.c:838:6: error: variable
'goa_even_valid' is used uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
838 |
From: Arnd Bergmann
ttm now directly calls into shmem code, which fails to build when
that is disabled at compile time.
ld.lld-21: error: undefined symbol: shmem_writeout
>>> referenced by ttm_backup.c
>>> drivers/gpu/drm/ttm/ttm_backup.o:(ttm_backup_backup_pag
From: Arnd Bergmann
clang points out that there is a code path that leads to undefined behavior:
drivers/gpu/drm/sysfb/efidrm.c:353:11: error: variable 'screen_base' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
353 |
On Thu, Apr 10, 2025, at 13:22, Matt Coster wrote:
> On 09/04/2025 13:22, Arnd Bergmann wrote:
>>
>> Rather than adding more #ifdef blocks, address this by changing the
>> existing #ifdef into equivalent IS_ENABLED() checks so gcc can see
>> where the symbol is used
On Wed, Apr 9, 2025, at 09:07, Arnd Bergmann wrote:
> On Tue, Apr 8, 2025, at 19:51, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> clang-16 and earlier complain about what it thinks might be an out of
>> range number:
>>
>> drivers/gpu/drm/bridge/synops
From: Arnd Bergmann
When CONFIG_DEBUG_FS is disabled, the stid_fmts[] array is not referenced
anywhere, causing a W=1 warning with gcc:
In file included from drivers/gpu/drm/imagination/pvr_fw_trace.c:7:
drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h:75:39: error: 'stid_fmts'
defin
From: Arnd Bergmann
Most patches I sent during the previous kernel cycle have made it in, these
ten still remain for the moment. Please apply.
Arnd Bergmann (10):
drm/imagination: avoid unused-const-variable warning
[v2] clocksource: atmel_tcb: fix kconfig dependency
[v2] Input: stmpe-ts
On Tue, Apr 8, 2025, at 19:51, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang-16 and earlier complain about what it thinks might be an out of
> range number:
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi2.c:348:8: error: call to
> __compiletime_assert_579 declared w
From: Arnd Bergmann
clang-16 and earlier complain about what it thinks might be an out of
range number:
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi2.c:348:8: error: call to
__compiletime_assert_579 declared with 'error' attribute: FIELD_PREP: value too
large for
On Tue, Apr 8, 2025, at 12:22, Geert Uytterhoeven wrote:
> On Mon, 7 Apr 2025 at 12:40, Arnd Bergmann wrote:
>
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -21,6 +21,7 @@ config GENERIC_PCI_IOMAP
>> menuconfig PCI
>> bool "PC
From: Arnd Bergmann
It turns out that there are no platforms that have PCI but don't have an MMU,
so adding a Kconfig dependency on CONFIG_PCI simplifies build testing kernels
for those platforms a lot, and avoids a lot of inadvertent build regressions.
Add a dependency for CONFIG_PC
From: Arnd Bergmann
Building the xe driver for i386 results in a link time warning:
x86_64-linux-ld: drivers/gpu/drm/xe/xe_migrate.o: in function `xe_migrate_vram':
xe_migrate.c:(.text+0x1e15): undefined reference to `__udivdi3'
Avoid this by using DIV_U64_ROUND_UP() instead of DI
From: Arnd Bergmann
This fails to build without the KMS helper functions:
x86_64-linux-ld: drivers/gpu/drm/bridge/tda998x_drv.o: in function
`tda998x_detect_work':
tda998x_drv.c:(.text+0x4e6): undefined reference to
`drm_kms_helper_hotplug_event'
x86_64-linux-ld: drivers/gpu/
On Fri, Mar 21, 2025, at 18:05, Guenter Roeck wrote:
> On 3/13/25 04:43, Alessandro Carminati wrote:
>
> gcc 10.3.0 and later do not have this problem. I also tried s390 builds
> with gcc 9.4
> and 9.5 but they both crash for unrelated reasons.
>
> If this is a concern, the best idea I have is to
3c24xx support")
>
> See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> Remove it.
>
> I've split this up based on the subcomponents to make the size
> of each patch sensible.
>
> Dave
>
> Signed-off-by: Dr. David Alan Gilbert
Looks all good to me. Whole series
Acked-by: Arnd Bergmann
From: Arnd Bergmann
The newly added driver uses the DSC helpers, so the corresponding
Kconfig option must be enabled:
ERROR: modpost: "drm_dsc_pps_payload_pack"
[drivers/gpu/drm/panel/panel-visionox-rm692e5.ko] undefined!
Fixes: 7cb3274341bf ("drm/panel: Add Visionox RM692
From: Arnd Bergmann
A size_t must be printed with the %z modifier instead of %l:
In file included from include/linux/device.h:15,
from include/linux/usb.h:19,
from drivers/gpu/drm/tiny/appletbdrm.c:19:
drivers/gpu/drm/tiny/appletbdrm.c: In function
On Mon, Mar 3, 2025, at 08:48, Andy Shevchenko wrote:
> On Fri, Feb 28, 2025 at 09:08:15PM +0200, Raag Jadav wrote:
>> > > > Ah, you mean devres related?
>> > >
>> > > Yeah, couldn't find it on Arnd's tree and I'm not sure if this series
>> > > works without it.
>> >
>> > But err.h is included in
On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote:
> On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote:
>> This series attempts to cleanup io.h with "include what you use" approach.
>> This depends on changes available on immutable tag[1].
>>
>> Although this series is too trivial in
From: Arnd Bergmann
The new audio code fails to build when sounds support is in a loadable
module but the GPU driver is built-in:
x86_64-linux-ld: zynqmp_dp_audio.c:(.text+0x6a8): undefined reference to
`devm_snd_soc_register_card'
x86_64-linux-ld: drivers/gpu/drm/xlnx/zynqmp_dp_au
On Wed, Feb 26, 2025, at 13:05, Javier Martinez Canillas wrote:
> "Arnd Bergmann" writes:
>> in drivers/video/console, with the simpler alternative just
>> calling into fbcon functions. I'm not sure if we can already drop
>> vgacon from normal x86-64 dis
On Wed, Feb 26, 2025, at 09:16, Thomas Zimmermann wrote:
> Am 26.02.25 um 08:55 schrieb Arnd Bergmann:
> Here's another general question. vgacon and fbcon only seem usable with
> CONFIG_VT=y. Wouldn't it make sense to have them depend on CONFIG_VT=y?
> dummycon could then
On Wed, Feb 26, 2025, at 08:48, Thomas Zimmermann wrote:
> Am 25.02.25 um 17:44 schrieb Arnd Bergmann:
>> From: Arnd Bergmann
>>
>> Dummycon is used as a fallback conswitchp for vgacon and fbcon
>> in the VT code, and there are no references to it if all three
>&g
From: Arnd Bergmann
Dummycon is used as a fallback conswitchp for vgacon and fbcon
in the VT code, and there are no references to it if all three
are disabled, so just leave it out of the kernel image for
configurations without those.
Signed-off-by: Arnd Bergmann
---
drivers/video/console
From: Arnd Bergmann
mdacon has roughly the same dependencies as vgacon but expresses them
as a negative list instead of a positive list, with the only practical
difference being PowerPC/CHRP, which uses vga16fb instead of vgacon.
The CONFIG_MDA_CONSOLE description advises to only turn it on
From: Arnd Bergmann
dummycon fails to build on ARM/footbridge when the VGA console is
disabled, since I got the dependencies slightly wrong in a previous
patch:
drivers/video/console/dummycon.c: In function 'dummycon_init':
drivers/video/console/dummycon.c:27
On Fri, Feb 21, 2025, at 17:50, Andy Shevchenko wrote:
> On Fri, Feb 21, 2025 at 11:15:47AM +0100, Arnd Bergmann wrote:
>> As you already found, removing an old indirect #include that is
>> no longer needed usually leads to some files breaking. The more
>> impactful your
On Fri, Feb 21, 2025, at 06:08, Raag Jadav wrote:
> In a wider effort to improve build speeds, we're attempting to split/cleanup
> core headers.
>
> This series attempts to cleanup io.h with "include what you need" approach.
>
> This depends on earlier modifications available in immutable tag[1]. F
On Sat, Feb 8, 2025, at 10:29, oushixiong1...@163.com wrote:
> From: Shixiong Ou
>
> 1. The device_remove_file() need to be called when driver is removing.
> 2. The device_remove_file() need to be called if the call to
>device_create_file() fails.
This should probably use device_add_group() i
On Tue, Feb 11, 2025, at 18:28, Jerome Brunet wrote:
>
> I also think this is more readeable and maintainable than a bunch of
> 'default CONFIG_FOO if CONFIG_FOO' for CONFIG_RESET_MESON_AUX. This approach
> also would have several pitfall, such as picking the value of the first
> config
> set
From: Arnd Bergmann
Without the DP helper code, the newly added displayport support
causes a link failure:
x86_64-linux-ld: drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.o: in function
`hibmc_dp_aux_init':
dp_aux.c:(.text+0x37e): undefined reference to `drm_dp_aux_init'
x86_64-linux-l
From: Arnd Bergmann
In the combination of DRM_KMS_HELPER=m, DRM_GEM_SHMEM_HELPER=y,
DRM_FBDEV_EMULATION=y,
The shmem code fails to link against the KMS helpers:
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_driver_fbdev_probe':
(.text+0xeec601): undefined referen
From: Arnd Bergmann
In the combination of DRM_KMS_HELPER=m, DRM_GEM_SHMEM_HELPER=y,
DRM_FBDEV_EMULATION=y,
The shmem code fails to link against the KMS helpers:
x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_driver_fbdev_probe':
(.text+0xeec601): undefined referen
On Sun, Dec 22, 2024, at 21:15, Helge Deller wrote:
> On 12/22/24 17:09, Thomas Zimmermann wrote:
+ depends on BACKLIGHT_CLASS_DEVICE=y ||
BACKLIGHT_CLASS_DEVICE=FB_NVIDIA
>>>
>>> Seems wrong. BACKLIGHT_CLASS_DEVICE is of type tristate.
>>> There are more of those, please check.
>>
>
On Wed, Dec 18, 2024, at 11:50, AngeloGioacchino Del Regno wrote:
> Il 18/12/24 09:58, Arnd Bergmann ha scritto:
>> From: Arnd Bergmann
>
> The problem is - no PHY no party, it's not going to work without... but
> I get the
> reasons behind this change.
>
> Are
From: Arnd Bergmann
This driver fails to build in random configurations:
drivers/accel/amdxdna/aie2_solver.c: In function 'remove_partition_node':
drivers/accel/amdxdna/aie2_solver.c:121:9: error: implicit declaration of
function 'kfree' [-Wimplicit-function-declaration]
From: Arnd Bergmann
The PHY portion of the mediatek hdmi driver was originally part of
the driver it self and later split out into drivers/phy, which a
'select' to keep the prior behavior.
However, this leads to build failures when the PHY driver cannot
be built:
WARNING: un
On Tue, Dec 17, 2024, at 21:14, Lucas De Marchi wrote:
> On Tue, Dec 17, 2024 at 08:28:59PM +0100, Arnd Bergmann wrote:
>>On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
>>> On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
>>>> From: Arnd Bergmann
&
On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
> On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
>>
>> x86_64-linux-ld: vmlinux.o: in f
From: Arnd Bergmann
When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init':
(.text+0x19861bf): undefined reference to `intel_vsec_register'
This could be enforced using a 'depends on INTEL_VSEC || !IN
rsion
in my randconfig test tree and have replaced it with yours now
to do some more regression testing, but I expect this to be fine.
Reviewed-by: Arnd Bergmann
From: Arnd Bergmann
Passing a variable string as a printf style format is potentially
dangerous that -Wformat-security can warn about if enabled. A new
instance just got added:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function 'dpu_kms_mdp_snapshot':
drivers/gpu/drm/msm/disp/dpu1
From: Arnd Bergmann
This driver fails to build in random configurations:
drivers/accel/amdxdna/amdxdna_mailbox.c:357:8: error: unknown type name
'irqreturn_t'
357 | static irqreturn_t mailbox_irq_handler(int irq, void *p)
|^~~
drivers/accel/amdxdna/amdxdna_mai
From: Arnd Bergmann
The old SET_SYSTEM_SLEEP_PM_OPS and SET_RUNTIME_PM_OPS macros cause a build
warning when CONFIG_PM is disabled:
drivers/accel/amdxdna/amdxdna_pci_drv.c:343:12: error: 'amdxdna_pmops_resume'
defined but not used [-Werror=unused-function]
343 |
On Thu, Dec 12, 2024, at 19:44, Helge Deller wrote:
> On 12/12/24 11:04, Thomas Zimmermann wrote:
>> Do not select BACKLIGHT_CLASS_DEVICE from FB_BACKLIGHT. The latter
>> only controls backlight support within fbdev core code and data
>> structures.
>>
>> Make fbdev drivers depend on BACKLIGHT_CLAS
From: Arnd Bergmann
Without fonts, this fails to link:
drivers/gpu/drm/clients/drm_log.o: in function `drm_log_init_client':
drm_log.c:(.text+0x3d4): undefined reference to `get_default_font'
Select this, like the other users do.
Fixes: f7b42442c4ac ("drm/log: Introduce a new
On Tue, Dec 10, 2024, at 15:09, Thomas Zimmermann wrote:
> Do not select BACKLIGHT_CLASS_DEVICE from FB_BACKLIGHT. The latter
> only controls backlight support within fbdev core code and data
> structures.
>
> Make fbdev drivers depend on BACKLIGHT_CLASS_DEVICE and let users
> select it explicitly.
On Fri, Nov 15, 2024, at 16:54, Thomas Zimmermann wrote:
> Am 15.11.24 um 16:27 schrieb Arnd Bergmann:
>>
>> @@ -220,7 +221,6 @@ config DRM_CLIENT_LIB
>> tristate
>> depends on DRM
>> select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
>> -
From: Arnd Bergmann
The 'select FB_CORE' statement moved from CONFIG_DRM to DRM_CLIENT_LIB,
but there are now configurations that have code calling into fb_core
as built-in even though the client_lib itself is a loadable module:
x86_64-linux-ld: drivers/gpu/drm/drm_fbdev_shmem.o: i
From: Arnd Bergmann
The 'select FB_CORE' statement moved from CONFIG_DRM to DRM_CLIENT_LIB,
but there are now configurations that have code calling into fb_core
as built-in even though the client_lib itself is a loadable module:
x86_64-linux-ld: drivers/gpu/drm/drm_fbdev_shmem.o: i
On Mon, Nov 4, 2024, at 13:24, Dmitry Baryshkov wrote:
> On Mon, Nov 04, 2024 at 02:10:54PM +0200, Laurentiu Palcu wrote:
>> On Mon, Oct 28, 2024 at 04:35:07PM +0000, Arnd Bergmann wrote:
>>> Fixes: 004555a18d57 ("drm/imx/dcss: Allow build with COMPILE_TEST=y")
>>
From: Arnd Bergmann
Compile-testing random configurations leads to failures in
dcss-kms.c from a missing declaration:
drivers/gpu/drm/imx/dcss/dcss-kms.c:95:8: error: use of undeclared identifier
'drm_bridge_attach'
95 | ret = drm_bridge_attach(encoder, br
On Mon, Oct 28, 2024, at 02:34, Stephen Rothwell wrote:
> -} else {
> +} else if (IS_ENABLED(CONFIG_HAS_IOPORT)) {
> ioaddr = VBE_DISPI_IOPORT_INDEX;
> iosize = 2;
> - if (!request_region(ioaddr, iosize, "bochs-drm")) {
> + if (!devm_re
a6xx_hfi_send_bw_table'
> [-Werror,-Wframe-larger-than]
>
> Fix this by kmalloc-ating struct a6xx_hfi_msg_bw_table instead of using
> the stack. Also, use this opportunity to skip re-initializing this table
> to optimize gpu wake up latency.
>
> Cc: Arnd Bergmann
Please chang
1 - 100 of 1282 matches
Mail list logo
