lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ab9f73d-ef7b-40b3-b2bb-650f83ac236f@amd.com>
Date: Tue, 23 Dec 2025 15:55:56 +0100
From: Christian König <christian.koenig@....com>
To: Arnd Bergmann <arnd@...db.de>, Han Gao <gaohan@...as.ac.cn>,
 Alex Deucher <alexander.deucher@....com>, Dave Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, amd-gfx@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Cc: Han Gao <rabenda.cn@...il.com>, linux-riscv@...ts.infradead.org,
 sophgo@...ts.linux.dev
Subject: Re: [PATCH] drm/radeon: bypass no_64bit_msi with new msi64 parameter

On 12/22/25 22:32, Arnd Bergmann wrote:
> On Sat, Dec 20, 2025, at 17:33, Han Gao wrote:
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 87fd6255c114..53af28494c03 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -249,6 +249,10 @@ int radeon_cik_support = -1;
>>  MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled, 0 = disabled, 
>> -1 = default)");
>>  module_param_named(cik_support, radeon_cik_support, int, 0444);
>>
>> +int radeon_msi64;
>> +MODULE_PARM_DESC(msi64, "MSI64 support (1 = enabled, 0 = disabled)");
>> +module_param_named(msi64, radeon_msi64, int, 0444);
>> +
> 
> As with the hda-intel patch, this should not be a module argument,
> but we should have the kernel figure out what to do itself.

Yeah, completely agree. This is basically just a workaround (and a bit ugly one).

>> diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
>> b/drivers/gpu/drm/radeon/radeon_irq_kms.c
>> index 9961251b44ba..62eb5a6968ff 100644
>> --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
>> @@ -250,7 +250,7 @@ static bool radeon_msi_ok(struct radeon_device 
>> *rdev)
>>  	 * of address for "64-bit" MSIs which breaks on some platforms, 
>> notably
>>  	 * IBM POWER servers, so we limit them
>>  	 */
>> -	if (rdev->family < CHIP_BONAIRE) {
>> +	if (rdev->family < CHIP_BONAIRE && !radeon_msi64) {
>>  		dev_info(rdev->dev, "radeon: MSI limited to 32-bit\n");
>>  		rdev->pdev->no_64bit_msi = 1;
> 
> According to the comment above it, the device can apparently
> do 40-bit addressing but not use the entire 64-bit space.
> 
> I assume the SG2042 chip has the irqchip somewhere above the
> 32-bit line but below the 40-bit line, so it ends up working.
> 
> I wonder if the msi_verify_entries() function should check
> against dev->coherent_dma_mask instead of checking the
> upper 32 bits for being nonzero, that probably gives you
> the desired behavior.

Again completely agree, that sounds like a plan to me.

IIRC the modified code here is basically just a workaround because the MSI control dword on older radeon HW was not setup correctly.

Regards,
Christian.

> 
>      Arnd


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ