From: Arnd Bergmann
Multiple files in amdgpu call amdgpu_ucode_request() with a fw_name
variable that the compiler cannot check for being a valid format string,
as seen by enabling the (default-disabled) -Wformat-security option:
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c: In function
On Tue, Jun 4, 2024, at 22:26, Alex Deucher wrote:
> Fixes: 669d6b078ed8 ("drm/amd/display: avoid large on-stack structures")
> Suggested-by: Hamza Mahfooz
> Signed-off-by: Alex Deucher
> Cc: George Zhang
> Cc: Arnd Bergmann
Acked-by: Arnd Bergmann
On Tue, Jun 4, 2024, at 16:22, Christian König wrote:
> Am 04.06.24 um 15:50 schrieb Alex Deucher:
>> This can be called in atomic context. Should fix:
>>
>> BUG: sleeping function called from invalid context at
>> include/linux/sched/mm.h:306
>> in_atomic(): 1, irqs_disabled(): 0, non_block: 0,
ge Zhang
> Suggested-by: Hamza Mahfooz
> Signed-off-by: Alex Deucher
> Cc: George Zhang
> Cc: Arnd Bergmann
> Cc: harry.wentl...@amd.com
> Cc: sunpeng...@amd.com
> Cc: rodrigo.sique...@amd.com
That looks nicer than all the other suggestions, thanks!
Acked-by: Arnd Bergmann
One
On Mon, Jun 3, 2024, at 22:59, George Zhang wrote:
> This reverts commit 416b5c5eec9e708b31c68f00cb79130f2cfaf7ed.
>
> This patch caused a regression on DCN 3.2 on the IGT test
> assr-links-suspend, with
> the dmesg warning:
>
> BUG: sleeping function called from invalid context at
> include/linu
From: Arnd Bergmann
The scaler_data structure is implicitly copied onto the stack twice by
being returned from a function. This is usually a bad idea, but it
was not flagged by the compiler until a recent addition that pushed
it over the 1024 byte function stack limit:
drivers/gpu/drm/amd
From: Arnd Bergmann
Putting excessively large objects on a function stack causes
a warning about possibly overflowing the 8KiB of kernel stack:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c: In
function 'dcn401_update_bw_bounding_box':
drivers/gpu/drm/
From: Arnd Bergmann
The graphics_object_id structure is meant to fit into 32 bits, as it's
passed by value in and out of functions. A recent change increased
the size to 128 bits, so it's now always passed by reference, which
is clearly not intended and ends up producing a compile-ti
From: Arnd Bergmann
This structure is too large to fit on a stack, as shown by the
newly introduced warnings from a recent code change:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c: In
function 'dcn32_update_bw_bounding_box':
drivers/gpu/drm/amd/amdgpu/../
From: Arnd Bergmann
The amdkfd support fails to link when CONFIG_CRC16 is disabled:
aarch64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_topology.o: in function
`kfd_topology_add_device':
kfd_topology.c:(.text+0x3a4c): undefined reference to `crc16'
This is a library module that n
From: Arnd Bergmann
The graphics_object_id structure is meant to fit into 32 bits, as it's
passed by value in and out of functions. A recent change increased
the size to 128 bits, so it's now always passed by reference, which
is clearly not intended and ends up producing a compile-ti
From: Arnd Bergmann
This structure is too large to fit on a stack, as shown by the
newly introduced warnings from a recent code change:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c: In
function 'dcn32_update_bw_bounding_box':
drivers/gpu/drm/amd/amdgpu/../
On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote:
> On Thu, 11 Apr 2024 at 03:11, Samuel Holland
> wrote:
>> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
>> > Samuel Holland writes:
>>
>> >> The short-term fix would be to drop the `select
>> >> ARCH_HAS_KERNEL_FPU_SUPPORT` for
>> >>
From: Arnd Bergmann
This is a follow-up on a couple of patch series I sent in the past,
enabling -Wextra (aside from stuff that is explicitly disabled),
-Wcast-function-pointer-strict and -Wrestrict.
I have tested these on 'defconfig' and 'allmodconfig' builds across
all ar
On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
>> On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
>>> On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote:
RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like sever
On Sat, Dec 9, 2023, at 22:29, Samuel Holland wrote:
> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
>>> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
>>>>
>>>> https://lore.kernel.org/20231019205117
From: Arnd Bergmann
gcc prints a warning about a possible array overflow for a couple of
callers of dp_decide_lane_settings() after commit 1b56c90018f0 ("Makefile:
Enable -Wstringop-overflow globally"):
drivers/gpu/drm/amd/amdgpu/../display/dc/link
On Tue, Sep 26, 2023, at 20:47, Deucher, Alexander wrote:
>> From: Arnd Bergmann
>> Subject: Re: [PATCH 2/2] drm/amdkfd: drop struct kfd_cu_info
>>
>> On Tue, Sep 26, 2023, at 18:39, Alex Deucher wrote:
>> > I think this was an abstraction back from when kfd supp
avoids having the kfd_cu_info structures on
> the stack when inlining which can blow up the stack.
>
> Cc: Arnd Bergmann
> Signed-off-by: Alex Deucher
Nice cleanup!
Acked-by: Arnd Bergmann
I guess you could fold patch 1/2 into this as it removes
all the added code from that anyway.
On Tue, Sep 26, 2023, at 18:39, Alex Deucher wrote:
> kfd_topology.c:2082:1: warning: the frame size of 1440 bytes is larger
> than 1024 bytes
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2866
> Cc: Arnd Bergmann
> Signed-off-by: Alex Deucher
Acked-by: Arnd Bergmann
From: Arnd Bergmann
When CONFIG_DYNAMIC_DEBUG is disabled altogether, calling
_dynamic_func_call_no_desc() does not work:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function
'svm_range_set_attr':
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:52:9: error: implicit
decl
From: Arnd Bergmann
On 32-bit architectures comparing a resource against a value larger than
U32_MAX can cause a warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'uns
On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
> Am 04.07.23 um 14:24 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 08:54, Christian König wrote:
>>> Am 03.07.23 um 14:35 schrieb Arnd Bergmann:
>> Not sure I understand the specific requirement. Do you mean the
On Tue, Jul 4, 2023, at 16:51, Christian König wrote:
> Am 04.07.23 um 16:31 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
>>>
>>> Modern AMD GPUs have 16GiB of local memory (VRAM), making those
>>> accessible to a CPU whic
On Tue, Jul 4, 2023, at 08:54, Christian König wrote:
> Am 03.07.23 um 14:35 schrieb Arnd Bergmann:
>> From: Arnd Bergmann
>>
>> On 32-bit architectures comparing a resource against a value larger than
>> U32_MAX can cause a warning:
>>
>> drivers/gpu/drm/am
From: Arnd Bergmann
On 32-bit architectures comparing a resource against a value larger than
U32_MAX can cause a warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'uns
From: Arnd Bergmann
The debugfs file is defined unconditionally, but the registration is hidden
in an #ifdef, which causes a warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c:110:37: error: unused variable
'amdgpu_rap_debugfs_ops' [-Werror,-Wunused-const-variable]
static co
From: Arnd Bergmann
Some of the newly introduced clear_address_watch callback handlers have
no prototype because they are only used in one file, which causes a W=1
warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c:164:10: error: no previous
prototype for
From: Arnd Bergmann
The .resync_fifo_dccg_dio() callback pointer was added in an #ifdef block,
but is called unconditionally:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c:2292:31:
error: 'struct hwseq_private_funcs' has no member named 'resync_fifo_dcc
From: Arnd Bergmann
Two newly introduced functions are in the global namespace but have no
prototypes
or callers outside of amdgpu_acpi.c, another function is static but only has
a caller inside of an #ifdef:
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:902:13: error: no previous prototype
for
From: Arnd Bergmann
DMA addresses can be shorter than u64, which results in a broken debug output:
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c: In function
'amdgpu_gart_table_ram_alloc':
drivers/gpu/drm/amd/amdgpu/amdgpu.h:41:22: error: format '%llx' expects
argument of type
From: Arnd Bergmann
A few newly added global functions have no prototype, which causes warnings:
drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c:169:5: error: no previous
prototype for 'aqua_vanjaram_select_scheds' [-Werror=missing-prototypes]
drivers/gpu/drm/
From: Arnd Bergmann
The file was newly added and causes some -Wmissing-prototype warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c:57:5: error: no previous
prototype for 'kgd_gfx_v9_4_3_hqd_sdma_load' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_
From: Arnd Bergmann
Two newly added functions cause a warning because they lack a prototype:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:1328:5: error:
no previous prototype for 'smu_v13_0_6_set_irq_state'
[-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/.
From: Arnd Bergmann
A global function without a header prototype has made it into
linux-next during the merge window:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6339:6: error: no
previous prototype for 'amdgpu_dm_connector_funcs_force'
[-Werror=missing-prototypes]
From: Arnd Bergmann
The only references to these variables were removed, so they now cause
warnings and have to be removed as well:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hwseq.c:226:20: error:
unused variable 'cmd' [-Werror,-Wunused-variable]
drivers/gpu/drm/
From: Arnd Bergmann
The dmub_abm_set_ambient_level() function has no caller and can
just be removed, the other ones have a declaration in the
header file and just need to see the prototype:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:122:14: error: no
previous prototype for
From: Arnd Bergmann
This was left global by accident, the corresponding functions for other
hardware types are already static:
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1072:6: error: no previous prototype
for function 'gfx_v9_4_3_disable_gpa_mode' [-Werror,-Wmissing-prototyp
On Mon, Apr 17, 2023, at 23:17, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> Three functions in the amdgpu display driver cause -Wmissing-prototype
>> warnings:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/c
From: Arnd Bergmann
Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
is_timing_changed() is actuall
On Mon, Apr 17, 2023, at 23:12, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> The newly introduced global function is not declared in a header or
>> called from another file, causing a harmless warning with sparse
>>
From: Arnd Bergmann
Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
drivers/gpu/drm/amd/amdgpu/
From: Arnd Bergmann
The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no
previous prototype for 'dccg314_init'
From: Arnd Bergmann
Global functions in radeon_atpx_handler.c are not declared in a header
but instead in each file using them. This risks the types getting out
of sync and causes warnings:
drivers/gpu/drm/radeon/radeon_atpx_handler.c:64:6: error: no previous prototype
for 'radeon_has
From: Arnd Bergmann
When CONFIG_DRM_AMD_DC_DCN is disabled, the is_frl member
is not defined:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c: In function
'dp_active_dongle_validate_timing':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:126:66: erro
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_comb
From: Arnd Bergmann
The newly added code is in an #ifdef, so the variables that
are only used in there cause a warning if CONFIG_DRM_AMD_DC_DCN
is disabled:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'amdgpu_dm_atomic_check':
drivers/gpu/drm/amd/amdgpu/
From: Arnd Bergmann
Some of the data structures are hidden when CONFIG_DRM_AMD_DC_DCN is
disabled, which leads to a link failure:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c:234:21:
error: 'union hdmi_encoded_link_bw' declared inside parameter list will not b
From: Arnd Bergmann
gcc-13 notices a mismatch between the return type of dp_retrieve_lttpr_cap()
and the returned value:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_capability.c: In function
'dp_retrieve_lttpr_cap':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dp_ca
From: Arnd Bergmann
The dp_retrieve_lttpr_cap() return type changed from 'bool'
to 'enum dc_status', so now the early 'return' uses the wrong
type:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
'dp_retrieve_lttpr_cap':
drive
On Thu, Dec 15, 2022, at 18:56, Michel Dänzer wrote:
> On 12/15/22 17:37, Arnd Bergmann wrote:
/amd/display/dc/core/dc_link_dp.c
>> index af9411ee3c74..95dbfa4e996a 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> +++ b/drivers/gpu/drm/amd/display
From: Arnd Bergmann
The .set_odm_combine callback pointer was added twice, causing
a harmless -Wextra warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_optc.c:258:36: error:
initialized field overwritten [-Werror=override-init]
258 | .set_odm_combine
From: Arnd Bergmann
The dp_retrieve_lttpr_cap() return type changed from 'bool'
to 'enum dc_status', so now the early 'return' uses the wrong
type:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
'dp_retrieve_lttpr_cap':
drive
From: Arnd Bergmann
The activity_monitor_external[] array is too big to fit on the
kernel stack, resulting in this warning with clang:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_7_ppt.c:1438:12: error:
stack frame size (1040) exceeds limit (1024) in
anic on most architectures. We'll revert this when the following bug report
> has been resolved: https://github.com/llvm/llvm-project/issues/41896.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/drm/Kconfig | 7 +++
> 1 file cha
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> bw_calcs() presently blows the stack-frame limit by calling functions
> inside a argument list which return quite a bit of data to be passed
> onto sub-functions. Simply breaking out this hunk reduces the
> stack-frame use by 500 Bytes, preventing
igned-off-by: Lee Jones
Acked-by: Arnd Bergmann
If this affects only clang but not gcc, I wonder if we could
limit the scope and keep the 1024 byte limit on gcc builds.
> ---
> lib/Kconfig.debug | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/Kconfig.debug b/l
anic on most architectures. We'll revert this when the following bug report
> has been resolved: https://github.com/llvm/llvm-project/issues/41896.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Lee Jones
Acked-by: Arnd Bergmann
f KASAN && !64BIT
>> default 1024 if !64BIT
>> default 2048 if 64BIT
>> help
>
> Note this also fixes 61 warnings when
>
> (GCC && !GCC_PLUGIN_LATENT_ENTROPY)
>
> ... which as Arnd says should not be enabled by default. We'll
> address that issue once this set has been applied.
Thanks a lot for checking this!
Reviewed-by: Arnd Bergmann
for ARM Neon.
>
> Signed-off-by: Ao Zhong
Looks good to me,
Acked-by: Arnd Bergmann
On Thu, Oct 27, 2022, at 16:45, Ao Zhong wrote:
> After moving all FPU code to the DML folder, we can enable DCN support
> for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the
> code in the DML folder that needs to use hardware FPU, and add a control
> mechanism for ARM Neon.
>
> S
On Thu, Oct 27, 2022, at 15:38, Ao Zhong wrote:
> Am Do., 27. Okt. 2022 um 12:52 Uhr schrieb Arnd Bergmann :
>
>> Why do you need separate $(dml_rcflags) and $(dml_rcflags_arm64)
>> rather than adding -mgeneral-regs-only to $(dml_rcflags) directly?
>
> I don't know if
On Thu, Oct 27, 2022, at 02:25, Ao Zhong wrote:
> After moving all FPU code to the DML folder, we can enable DCN support
> for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG from the
> code in the DML folder that needs to use hardware FPU, and add a control
> mechanism for ARM Neon.
>
> S
On Fri, Aug 5, 2022 at 8:02 PM Nathan Chancellor wrote:
> On Fri, Aug 05, 2022 at 06:16:45PM +0200, Arnd Bergmann wrote:
> > On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland
> > wrote:
> > While splitting out sub-functions can help reduce the maximum stack
> > usage, it
On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland wrote:
> > I do notice that these files build with a non-configurable
> > -Wframe-large-than value:
> >
> > $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
> > 54:frame_warn_flag := -Wframe-larger-than=2048
>
> Tbh, I was looking at th
On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds
wrote:
>
> On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
> wrote:cov_trace_cmp
> >
> > git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
> > display engine with KCOV enabled").
>
> Ahh. So that was presumably why
On Wed, May 25, 2022 at 11:35 PM kernel test robot wrote:
> .__mulsi3.o.cmd: No such file or directory
> Makefile:686: arch/h8300/Makefile: No such file or directory
> Makefile:765: arch/h8300/Makefile: No such file or directory
> arch/Kconfig:10: can't open file "arch/h8300/Kconfig"
Please stop
From: Arnd Bergmann
It appears that the wrong argument was removed in this call:
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:1694:36:
error
From: Arnd Bergmann
The overflow check in amdgpu_bo_list_create() causes a warning with
clang-14 on 64-bit architectures, since the limit can never be
exceeded.
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison
of constant 256204778801521549 with expression of type
From: Arnd Bergmann
The two AMD drivers have their own custom offsetof() implementation
that now triggers a warning with recent versions of clang:
drivers/gpu/drm/radeon/radeon_atombios.c:133:14: error: performing pointer
subtraction with a null pointer has undefined behavior
[-Werror,-Wnull
From: Arnd Bergmann
clang-14 points out that comparing an 'unsigned int' against a large
64-bit constantn is pointless:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1206:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka
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_comb
On Wed, Sep 8, 2021 at 10:55 PM Nathan Chancellor wrote:
> On Tue, Sep 07, 2021 at 11:11:17AM +0200, Arnd Bergmann wrote:
> > On Tue, Sep 7, 2021 at 4:32 AM Nathan Chancellor wrote:
function 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than]
> > > arm32-fedora.log:
>
From: Arnd Bergmann
Using an empty macro expansion as a conditional expression
produces a W=1 warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c: In function
'dce_aux_transfer_with_retries':
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:775:156: error: sugge
.
You can get these numbers by recompiling the file with the frame
size warning set to a low value, e.g. adding -Wframe-larger-than=100
to the command line.
Acked-by: Arnd Bergmann
On Thu, Sep 9, 2021 at 1:43 PM Marco Elver wrote:
> On Thu, 9 Sept 2021 at 13:00, Arnd Bergmann wrote:
> > On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote:
> > > On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig
> > > wrote:
> > > > On Wed, Sep 08, 2021
On Thu, Sep 9, 2021 at 12:54 PM Marco Elver wrote:
> On Thu, 9 Sept 2021 at 07:59, Christoph Hellwig wrote:
> > On Wed, Sep 08, 2021 at 11:58:56PM +0200, Marco Elver wrote:
> > > It'd be good to avoid. It has helped uncover build issues with KASAN in
> > > the past. Or at least make it dependent
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
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
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
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/
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
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 func
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 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
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]
timin
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
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
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
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 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
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
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 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
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
1 - 100 of 199 matches
Mail list logo