Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware.
Ast currently blanks via sync-off bits in VGACRB6. Not all BMCs handle VGACRB6 correctly. After disabling sync during a reboot, some BMCs do not reenable it after the soft reset. The display output remains dark. When the display is off during boot, some BMCs set the sync-off bits in VGACRB6, so the display remains dark. Observed with Blackbird AST2500 BMCs. Clearing the sync-off bits unconditionally fixes these issues.
Also do not modify VGASR1's SD bit for blanking, as it only disables GPU access to video memory.
v2: - init vgacrb6 correctly (Jocelyn)
Signed-off-by: Thomas Zimmermann tzimmermann@suse.de Fixes: ce3d99c83495 ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") Tested-by: Nick Bowler nbowler@draconx.ca Reported-by: Nick Bowler nbowler@draconx.ca Closes: https://lore.kernel.org/dri-devel/wpwd7rit6t4mnu6kdqbtsnk5bhftgslio6e2jgkz6k... Cc: Douglas Anderson dianders@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Thomas Zimmermann tzimmermann@suse.de Cc: Jocelyn Falempe jfalempe@redhat.com Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.7+ --- drivers/gpu/drm/ast/ast_mode.c | 18 ++++++++++-------- drivers/gpu/drm/ast/ast_reg.h | 1 + 2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 6b9d510c509d..9b6a7c54fbb5 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -836,22 +836,24 @@ ast_crtc_helper_atomic_flush(struct drm_crtc *crtc, static void ast_crtc_helper_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct ast_device *ast = to_ast_device(crtc->dev); + u8 vgacr17 = 0x00; + u8 vgacrb6 = 0xff;
- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, 0x00); - ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, 0x00); + vgacr17 |= AST_IO_VGACR17_SYNC_ENABLE; + vgacrb6 &= ~(AST_IO_VGACRB6_VSYNC_OFF | AST_IO_VGACRB6_HSYNC_OFF); + + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17); + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); }
static void ast_crtc_helper_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc); struct ast_device *ast = to_ast_device(crtc->dev); - u8 vgacrb6; + u8 vgacr17 = 0xff;
- ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, AST_IO_VGASR1_SD); - - vgacrb6 = AST_IO_VGACRB6_VSYNC_OFF | - AST_IO_VGACRB6_HSYNC_OFF; - ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); + vgacr17 &= ~AST_IO_VGACR17_SYNC_ENABLE; + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17);
/* * HW cursors require the underlying primary plane and CRTC to diff --git a/drivers/gpu/drm/ast/ast_reg.h b/drivers/gpu/drm/ast/ast_reg.h index e15adaf3a80e..30578e3b07e4 100644 --- a/drivers/gpu/drm/ast/ast_reg.h +++ b/drivers/gpu/drm/ast/ast_reg.h @@ -29,6 +29,7 @@ #define AST_IO_VGAGRI (0x4E)
#define AST_IO_VGACRI (0x54) +#define AST_IO_VGACR17_SYNC_ENABLE BIT(7) /* called "Hardware reset" in docs */ #define AST_IO_VGACR80_PASSWORD (0xa8) #define AST_IO_VGACR99_VGAMEM_RSRV_MASK GENMASK(1, 0) #define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1)
On 14/10/2025 10:46, Thomas Zimmermann wrote:
Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware.
Ast currently blanks via sync-off bits in VGACRB6. Not all BMCs handle VGACRB6 correctly. After disabling sync during a reboot, some BMCs do not reenable it after the soft reset. The display output remains dark. When the display is off during boot, some BMCs set the sync-off bits in VGACRB6, so the display remains dark. Observed with Blackbird AST2500 BMCs. Clearing the sync-off bits unconditionally fixes these issues.
Also do not modify VGASR1's SD bit for blanking, as it only disables GPU access to video memory.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe jfalempe@redhat.com
v2:
- init vgacrb6 correctly (Jocelyn)
Signed-off-by: Thomas Zimmermann tzimmermann@suse.de Fixes: ce3d99c83495 ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") Tested-by: Nick Bowler nbowler@draconx.ca Reported-by: Nick Bowler nbowler@draconx.ca Closes: https://lore.kernel.org/dri-devel/wpwd7rit6t4mnu6kdqbtsnk5bhftgslio6e2jgkz6k... Cc: Douglas Anderson dianders@chromium.org Cc: Dave Airlie airlied@redhat.com Cc: Thomas Zimmermann tzimmermann@suse.de Cc: Jocelyn Falempe jfalempe@redhat.com Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org # v6.7+
drivers/gpu/drm/ast/ast_mode.c | 18 ++++++++++-------- drivers/gpu/drm/ast/ast_reg.h | 1 + 2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 6b9d510c509d..9b6a7c54fbb5 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -836,22 +836,24 @@ ast_crtc_helper_atomic_flush(struct drm_crtc *crtc, static void ast_crtc_helper_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct ast_device *ast = to_ast_device(crtc->dev);
- u8 vgacr17 = 0x00;
- u8 vgacrb6 = 0xff;
- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, 0x00);
- ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, 0x00);
- vgacr17 |= AST_IO_VGACR17_SYNC_ENABLE;
- vgacrb6 &= ~(AST_IO_VGACRB6_VSYNC_OFF | AST_IO_VGACRB6_HSYNC_OFF);
- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17);
- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); }
static void ast_crtc_helper_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc); struct ast_device *ast = to_ast_device(crtc->dev);
- u8 vgacrb6;
- u8 vgacr17 = 0xff;
- ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, AST_IO_VGASR1_SD);
- vgacrb6 = AST_IO_VGACRB6_VSYNC_OFF |
AST_IO_VGACRB6_HSYNC_OFF;- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6);
- vgacr17 &= ~AST_IO_VGACR17_SYNC_ENABLE;
- ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17);
/* * HW cursors require the underlying primary plane and CRTC to diff --git a/drivers/gpu/drm/ast/ast_reg.h b/drivers/gpu/drm/ast/ast_reg.h index e15adaf3a80e..30578e3b07e4 100644 --- a/drivers/gpu/drm/ast/ast_reg.h +++ b/drivers/gpu/drm/ast/ast_reg.h @@ -29,6 +29,7 @@ #define AST_IO_VGAGRI (0x4E) #define AST_IO_VGACRI (0x54) +#define AST_IO_VGACR17_SYNC_ENABLE BIT(7) /* called "Hardware reset" in docs */ #define AST_IO_VGACR80_PASSWORD (0xa8) #define AST_IO_VGACR99_VGAMEM_RSRV_MASK GENMASK(1, 0) #define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1)
#regzbot introduced: 6f719373b943a955fee6fc2012aed207b65e2854
Hi all,
I have encountered a serious (for me) regression with 6.18-rc2 on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. After booting, my console screen goes blank and stays blank. 6.18-rc1 was still fine.
The machine has an Asus Z9PE-D16 server mainboard with an onboard ASpeed AST2300 VGA chip with 16MB VRAM. I have attached an older HP Monitor to it via old VGA jack/cable. It also has a second graphics card in a PCI-E slot; an older NVidia GTX 560. It is not connected to a monitor, but I have configured it via kernel command line for PCI-pass-through to VMs running on this server (I use Proxmox VE, i.e. QEMU/KVM virtual machines). Currently, no VMs use this yet, and also no VMs are autostarting with machine boot. So when this regression occurs, the server is idle. Pressing a key on the keyboard does not make the screen come alive. The server is running fine though, and I can access it via SSH. It just has no graphic output anymore. In case this is important, the machine also has a ASMB6 BMC (can be used via http).
I have attached dmesg output from both 6.18-rc1 which is fine, and 6.18-rc2 which exhibits this bug. I have bisected the issue, please see attached git bisect.log.
The bad commit is
commit 6f719373b943a955fee6fc2012aed207b65e2854 Author: Thomas Zimmermann tzimmermann@suse.de Date: Tue Oct 14 10:46:34 2025 +0200
drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off
Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware.
When I revert this from 6.18-rc2, the issue goes away and my console screen works again.
I just saw that Greg just yesterday evening included the offending patch already in stable RCs 6.12.55-rc1 and 6.17.5-rc1, so I'll test these seperately and send a mail to the stable mailing list, too, if affected (which I anticipate).
Beste Grüße, Peter Schneider
Hi
Am 22.10.25 um 05:27 schrieb Peter Schneider:
#regzbot introduced: 6f719373b943a955fee6fc2012aed207b65e2854
Hi all,
I have encountered a serious (for me) regression with 6.18-rc2 on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. After booting, my console screen goes blank and stays blank. 6.18-rc1 was still fine.
The machine has an Asus Z9PE-D16 server mainboard with an onboard ASpeed AST2300 VGA chip with 16MB VRAM. I have attached an older HP Monitor to it via old VGA jack/cable. It also has a second graphics card in a PCI-E slot; an older NVidia GTX 560. It is not connected to a monitor, but I have configured it via kernel command line for PCI-pass-through to VMs running on this server (I use Proxmox VE, i.e. QEMU/KVM virtual machines). Currently, no VMs use this yet, and also no VMs are autostarting with machine boot. So when this regression occurs, the server is idle. Pressing a key on the keyboard does not make the screen come alive. The server is running fine though, and I can access it via SSH. It just has no graphic output anymore. In case this is important, the machine also has a ASMB6 BMC (can be used via http).
I have attached dmesg output from both 6.18-rc1 which is fine, and 6.18-rc2 which exhibits this bug. I have bisected the issue, please see attached git bisect.log.
Thanks for the detailed bug report.
Attached is a patch that partially reverts the broken commit. Could you please apply it on top of the broken kernel and report on the results?
Best regards Thomas
The bad commit is
commit 6f719373b943a955fee6fc2012aed207b65e2854 Author: Thomas Zimmermann tzimmermann@suse.de Date: Tue Oct 14 10:46:34 2025 +0200
drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off
Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware.
When I revert this from 6.18-rc2, the issue goes away and my console screen works again.
I just saw that Greg just yesterday evening included the offending patch already in stable RCs 6.12.55-rc1 and 6.17.5-rc1, so I'll test these seperately and send a mail to the stable mailing list, too, if affected (which I anticipate).
Beste Grüße, Peter Schneider
Hi Thomas,
thanks very much for your quick response!
(adding Thorsten to CC)
Am 22.10.2025 um 08:51 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 05:27 schrieb Peter Schneider:
#regzbot introduced: 6f719373b943a955fee6fc2012aed207b65e2854
Hi all,
I have encountered a serious (for me) regression with 6.18-rc2 on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. After booting, my console screen goes blank and stays blank. 6.18-rc1 was still fine.
The machine has an Asus Z9PE-D16 server mainboard with an onboard ASpeed AST2300 VGA chip with 16MB VRAM. I have attached an older HP Monitor to it via old VGA jack/cable. It also has a second graphics card in a PCI-E slot; an older NVidia GTX 560. It is not connected to a monitor, but I have configured it via kernel command line for PCI-pass- through to VMs running on this server (I use Proxmox VE, i.e. QEMU/KVM virtual machines). Currently, no VMs use this yet, and also no VMs are autostarting with machine boot. So when this regression occurs, the server is idle. Pressing a key on the keyboard does not make the screen come alive. The server is running fine though, and I can access it via SSH. It just has no graphic output anymore. In case this is important, the machine also has a ASMB6 BMC (can be used via http).
I have attached dmesg output from both 6.18-rc1 which is fine, and 6.18-rc2 which exhibits this bug. I have bisected the issue, please see attached git bisect.log.
Thanks for the detailed bug report.
Attached is a patch that partially reverts the broken commit. Could you please apply it on top of the broken kernel and report on the results?
Best regards Thomas
Your patch applied cleanly against 6.18-rc2 and the kernel built fine, but unfortunately it did not solve the issue: my console screen stays blank after booting. This is regardless whether I do a soft reboot, press the reset button or power cycle and do a cold boot. They are all the same.
Beste Grüße, Peter Schneider
Hi
Am 22.10.25 um 10:08 schrieb Peter Schneider:
Hi Thomas,
thanks very much for your quick response!
(adding Thorsten to CC)
Am 22.10.2025 um 08:51 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 05:27 schrieb Peter Schneider:
#regzbot introduced: 6f719373b943a955fee6fc2012aed207b65e2854
Hi all,
I have encountered a serious (for me) regression with 6.18-rc2 on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. After booting, my console screen goes blank and stays blank. 6.18-rc1 was still fine.
The machine has an Asus Z9PE-D16 server mainboard with an onboard ASpeed AST2300 VGA chip with 16MB VRAM. I have attached an older HP Monitor to it via old VGA jack/cable. It also has a second graphics card in a PCI-E slot; an older NVidia GTX 560. It is not connected to a monitor, but I have configured it via kernel command line for PCI-pass- through to VMs running on this server (I use Proxmox VE, i.e. QEMU/KVM virtual machines). Currently, no VMs use this yet, and also no VMs are autostarting with machine boot. So when this regression occurs, the server is idle. Pressing a key on the keyboard does not make the screen come alive. The server is running fine though, and I can access it via SSH. It just has no graphic output anymore. In case this is important, the machine also has a ASMB6 BMC (can be used via http).
I have attached dmesg output from both 6.18-rc1 which is fine, and 6.18-rc2 which exhibits this bug. I have bisected the issue, please see attached git bisect.log.
Thanks for the detailed bug report.
Attached is a patch that partially reverts the broken commit. Could you please apply it on top of the broken kernel and report on the results?
Best regards Thomas
Your patch applied cleanly against 6.18-rc2 and the kernel built fine, but unfortunately it did not solve the issue: my console screen stays blank after booting. This is regardless whether I do a soft reboot, press the reset button or power cycle and do a cold boot. They are all the same.
Just to be sure: you do see output at the early boot stages (BIOS, boot loader). It's at some later point during boot, the driver loads and the display blanks out?
There's another patch attached. does this make a difference?
Best regards Thomas
Beste Grüße, Peter Schneider
Am 22.10.2025 um 11:11 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 10:08 schrieb Peter Schneider:
Your patch applied cleanly against 6.18-rc2 and the kernel built fine, but unfortunately it did not solve the issue: my console screen stays blank after booting. This is regardless whether I do a soft reboot, press the reset button or power cycle and do a cold boot. They are all the same.
Just to be sure: you do see output at the early boot stages (BIOS, boot loader). It's at some later point during boot, the driver loads and the display blanks out?
Yes, that's correct.
There's another patch attached. does this make a difference?
Do I have to apply that against base 6.18-rc2 or against 6.18-rc2 + your previous patch?
Beste Grüße, Peter Schneider
Hi
Am 22.10.25 um 11:16 schrieb Peter Schneider:
Am 22.10.2025 um 11:11 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 10:08 schrieb Peter Schneider:
Your patch applied cleanly against 6.18-rc2 and the kernel built fine, but unfortunately it did not solve the issue: my console screen stays blank after booting. This is regardless whether I do a soft reboot, press the reset button or power cycle and do a cold boot. They are all the same.
Just to be sure: you do see output at the early boot stages (BIOS, boot loader). It's at some later point during boot, the driver loads and the display blanks out?
Yes, that's correct.
There's another patch attached. does this make a difference?
Do I have to apply that against base 6.18-rc2 or against 6.18-rc2 + your previous patch?
Base 6.18-rc2. All the patches are against this.
Best regards Thomas
Beste Grüße, Peter Schneider
Am 22.10.2025 um 12:20 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 11:16 schrieb Peter Schneider:
Am 22.10.2025 um 11:11 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 10:08 schrieb Peter Schneider:
Your patch applied cleanly against 6.18-rc2 and the kernel built fine, but unfortunately it did not solve the issue: my console screen stays blank after booting. This is regardless whether I do a soft reboot, press the reset button or power cycle and do a cold boot. They are all the same.
Just to be sure: you do see output at the early boot stages (BIOS, boot loader). It's at some later point during boot, the driver loads and the display blanks out?
Yes, that's correct.
There's another patch attached. does this make a difference?
Do I have to apply that against base 6.18-rc2 or against 6.18-rc2 + your previous patch?
Base 6.18-rc2. All the patches are against this.
So with this new patch against 6.18-rc2, I first got this build error:
CC [M] drivers/gpu/drm/ast/ast_mode.o drivers/gpu/drm/ast/ast_mode.c: In function ‘ast_crtc_helper_atomic_disable’: drivers/gpu/drm/ast/ast_mode.c:857:12: error: unused variable ‘vgacr17’ [-Werror=unused-variable] 857 | u8 vgacr17 = 0xff; | ^~~~~~~ cc1: all warnings being treated as errors
because I always do my kernel builds with CONFIG_WERROR=y. So then I commented out the now superfluous declaration in line 857 and the build succeeded. However, unfortunately the issue still persists. The screen still gets blanked on reboot (as clarified before, after BIOS/POST messages, Grub boot menu, initial boot messages).
Beste Grüße, Peter Schneider
Hi
Am 22.10.25 um 13:23 schrieb Peter Schneider:
Am 22.10.2025 um 12:20 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 11:16 schrieb Peter Schneider:
Am 22.10.2025 um 11:11 schrieb Thomas Zimmermann:
Hi
Am 22.10.25 um 10:08 schrieb Peter Schneider:
Your patch applied cleanly against 6.18-rc2 and the kernel built fine, but unfortunately it did not solve the issue: my console screen stays blank after booting. This is regardless whether I do a soft reboot, press the reset button or power cycle and do a cold boot. They are all the same.
Just to be sure: you do see output at the early boot stages (BIOS, boot loader). It's at some later point during boot, the driver loads and the display blanks out?
Yes, that's correct.
There's another patch attached. does this make a difference?
Do I have to apply that against base 6.18-rc2 or against 6.18-rc2 + your previous patch?
Base 6.18-rc2. All the patches are against this.
So with this new patch against 6.18-rc2, I first got this build error:
CC [M] drivers/gpu/drm/ast/ast_mode.o drivers/gpu/drm/ast/ast_mode.c: In function ‘ast_crtc_helper_atomic_disable’: drivers/gpu/drm/ast/ast_mode.c:857:12: error: unused variable ‘vgacr17’ [-Werror=unused-variable] 857 | u8 vgacr17 = 0xff; | ^~~~~~~ cc1: all warnings being treated as errors
because I always do my kernel builds with CONFIG_WERROR=y. So then I commented out the now superfluous declaration in line 857 and the build succeeded. However, unfortunately the issue still persists. The screen still gets blanked on reboot (as clarified before, after BIOS/POST messages, Grub boot menu, initial boot messages).
I've been able to reproduce the problem with an AST2300 test system. The attached patch fixes the problem for me. Can you please test and report on the results?
Best regards Thomas
Beste Grüße, Peter Schneider
I've been able to reproduce the problem with an AST2300 test system. The attached patch fixes the problem for me. Can you please test and report on the results?
On pure -rc2 without previous patches applied.
Hi Thomas,
Am 23.10.2025 um 14:46 schrieb Thomas Zimmermann: [...]
I've been able to reproduce the problem with an AST2300 test system. The attached patch fixes the problem for me. Can you please test and report on the results?
Great! - this patch on top of 6.18-rc2 fixes the issue for me, too. Thanks very much for your effort!
Tested-by: Peter Schneider pschneider1968@googlemail.com
Beste Grüße, Peter Schneider
Hi Thomas,
Am 23.10.2025 um 21:11 schrieb Peter Schneider:
Hi Thomas,
Am 23.10.2025 um 14:46 schrieb Thomas Zimmermann: [...]
I've been able to reproduce the problem with an AST2300 test system. The attached patch fixes the problem for me. Can you please test and report on the results?
Great! - this patch on top of 6.18-rc2 fixes the issue for me, too. Thanks very much for your effort!
Tested-by: Peter Schneider pschneider1968@googlemail.com
Meanwhile, I have also tested this against stable 6.12.55 and 6.17.5, where in -rc2, Greg dropped your original patch with upstream commit-id 6f719373b943a955fee6fc2012aed207b65e2854 before the final release because of my report.
So for both, I built them, made sure it worked ok. Then I did "git cherry-pick 6f719373b943a955fee6fc2012aed207b65e2854" and tested that it is broken again. Then I applied your last patch on top of it, and it worked fine, so with that the issue is fixed in both stable versions, too.
If you send a combined patch to Greg for stable, please feel free to add my
Tested-by: Peter Schneider pschneider1968@googlemail.com
Thanks again!
Beste Grüße, Peter Schneider
Hi
Am 23.10.25 um 21:11 schrieb Peter Schneider:
Hi Thomas,
Am 23.10.2025 um 14:46 schrieb Thomas Zimmermann: [...]
I've been able to reproduce the problem with an AST2300 test system. The attached patch fixes the problem for me. Can you please test and report on the results?
Great! - this patch on top of 6.18-rc2 fixes the issue for me, too. Thanks very much for your effort!
Tested-by: Peter Schneider pschneider1968@googlemail.com
Thanks a lot for reporting and testing. I'll prepare the patch and send it out later today.
Best regards Thomas
Beste Grüße, Peter Schneider
linux-stable-mirror@lists.linaro.org
-
Jocelyn Falempe -
Peter Schneider -
Thomas Zimmermann