Skip to contentSkip to conversation

mtd: maps: vmu-flash: Fix build and runtime errors

PATCH Superseded Florian Fuchs 3 participants 10 messages Nov 17, 2025 – Nov 20, 2025

Subsystems (2)
Memory technology devices (MTD) SuperH

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore

Florian Fuchs

author
#0 lore raw

cover mtd: maps: vmu-flash: Fix build and runtime errors

Hi all,

This small series fixes build and runtime errors in the vmu-flash driver (enabled by CONFIG_MTD_VMU) and the included maple.h. These changes were verified on real Dreamcast hardware with a physical VMU. The VMU can now be successfully probed, read and written with MTD tools like mtd_info and mtd_debug. Previously, the driver failed to build or crashed during probing.

bash-5.3# mtdinfo /dev/mtd0
mtd0
Name: vmu2.1.0
Type: mlc-nand
Eraseblock size: 512 bytes
Amount of eraseblocks: 256 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 512 bytes
Sub-page size: 512 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true

Thanks,
Florian

Florian Fuchs (3):
sh: maple: Fix build error due to missing include of linux/device.h
mtd: maps: vmu-flash: Fix fault in unaligned fixup
mtd: maps: vmu-flash: Fix NULL pointer dereference in initialization

 drivers/mtd/maps/vmu-flash.c | 8 +++++---
 include/linux/maple.h        | 2 --
 2 files changed, 5 insertions(+), 5 deletions(-)

base-commit: 97315e7c901a1de60e8ca9b11e0e96d0f9253e18

Signature · 1 line
2.43.0
author
#1 lore raw

PATCH 1/3 sh: maple: Fix build error due to missing include of linux/device.h

Commit 313162d0b838 ("device.h: audit and cleanup users in main include dir") removed the include of linux/device.h. Revert this, as linux/maple.h embeds struct device via struct maple_device, which requires the definition. Otherwise results in build error: field 'dev' has incomplete type.

Fixes 313162d0b838 ("device.h: audit and cleanup users in main include dir")
Signed-off-by Florian Fuchs <[email protected]>
---
 include/linux/maple.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
include/linux/maple.h +1 -2
index 3be4e567473c..22f2930251ed 100644
@@ -2,10 +2,9 @@
 #ifndef __LINUX_MAPLE_H
 #define __LINUX_MAPLE_H
 
+#include <linux/device.h>
 #include <mach/maple.h>
 
-struct device;
-
 /* Maple Bus command and response codes */
 enum maple_code {
 	MAPLE_RESPONSE_FILEERR =	-5,

base-commit: 97315e7c901a1de60e8ca9b11e0e96d0f9253e18

Signature · 1 line
2.43.0
author
#2 lore raw

PATCH 2/3 mtd: maps: vmu-flash: Fix fault in unaligned fixup

In reply to Florian Fuchs

Use kcalloc() / kzalloc() to allocate the memcard structs, instead of kmalloc() / kmalloc_array() to prevent access to uninitialized data.

This fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.

Signed-off-by Florian Fuchs <[email protected]>
---
 drivers/mtd/maps/vmu-flash.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mtd/maps/vmu-flash.c +3 -3
index 53019d313db7..d0793f1b0fac 100644
@@ -609,7 +609,7 @@ static int vmu_connect(struct maple_device *mdev)
 
 	basic_flash_data = be32_to_cpu(mdev->devinfo.function_data[c - 1]);
 
-	card = kmalloc(sizeof(struct memcard), GFP_KERNEL);
+	card = kzalloc(sizeof(struct memcard), GFP_KERNEL);
 	if (!card) {
 		error = -ENOMEM;
 		goto fail_nomem;

@@ -627,14 +627,14 @@ static int vmu_connect(struct maple_device *mdev)
 	* Not sure there are actually any multi-partition devices in the
 	* real world, but the hardware supports them, so, so will we
 	*/
-	card->parts = kmalloc_array(card->partitions, sizeof(struct vmupart),
+	card->parts = kcalloc(card->partitions, sizeof(struct vmupart),
 				    GFP_KERNEL);
 	if (!card->parts) {
 		error = -ENOMEM;
 		goto fail_partitions;
 	}
 
-	card->mtd = kmalloc_array(card->partitions, sizeof(struct mtd_info),
+	card->mtd = kcalloc(card->partitions, sizeof(struct mtd_info),
 				  GFP_KERNEL);
 	if (!card->mtd) {
 		error = -ENOMEM;
Signature · 1 line
2.43.0
author
#3 lore raw

PATCH 3/3 mtd: maps: vmu-flash: Fix NULL pointer dereference in initialization

In reply to Florian Fuchs

The mtd_info contains a struct device, which must be linked to its parent. Without this, the initialization of the MTD fails with a NULL pointer dereference.

Signed-off-by Florian Fuchs <[email protected]>
---
 drivers/mtd/maps/vmu-flash.c | 1 +
 1 file changed, 1 insertion(+)
drivers/mtd/maps/vmu-flash.c +1 -0
index d0793f1b0fac..153ba6f8f769 100644
@@ -547,6 +547,7 @@ static void vmu_queryblocks(struct mapleq *mq)
 	mpart->partition = card->partition;
 	mtd_cur->priv = mpart;
 	mtd_cur->owner = THIS_MODULE;
+	mtd_cur->dev.parent = &mdev->dev;
 
 	pcache = kzalloc(sizeof(struct vmu_cache), GFP_KERNEL);
 	if (!pcache)
Signature · 1 line
2.43.0
maintainer
#4 lore raw
In reply to Florian Fuchs

Hi Florian,

Quoted 7 lines · Florian Fuchs

This small series fixes build and runtime errors in the vmu-flash driver (enabled by CONFIG_MTD_VMU) and the included maple.h. These changes were verified on real Dreamcast hardware with a physical VMU. The VMU can now be successfully probed, read and written with MTD tools like mtd_info and mtd_debug. Previously, the driver failed to build or crashed during probing.

Quoted 11 lines

bash-5.3# mtdinfo /dev/mtd0
mtd0
Name: vmu2.1.0
Type: mlc-nand
Eraseblock size: 512 bytes
Amount of eraseblocks: 256 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 512 bytes
Sub-page size: 512 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true

Thanks again for this series. Before this can be picked up, I would like again Artur Rojek to test it on his Dreamcast, so let's loop him in.

If he confirms the functionality, I'll pick it up. I'll try to get it reviewed later this week.

Adrian

Signature · 4 lines
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
#5 lore raw
Quoted 22 lines · John Paul Adrian Glaubitz

Hi Florian,

Quoted 7 lines · Florian Fuchs

This small series fixes build and runtime errors in the vmu-flash driver (enabled by CONFIG_MTD_VMU) and the included maple.h. These changes were verified on real Dreamcast hardware with a physical VMU. The VMU can now be successfully probed, read and written with MTD tools like mtd_info and mtd_debug. Previously, the driver failed to build or crashed during probing.

Quoted 11 lines

bash-5.3# mtdinfo /dev/mtd0
mtd0
Name: vmu2.1.0
Type: mlc-nand
Eraseblock size: 512 bytes
Amount of eraseblocks: 256 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 512 bytes
Sub-page size: 512 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true

Quoted 7 lines

Thanks again for this series. Before this can be picked up, I would like again Artur Rojek to test it on his Dreamcast, so let's loop him in.

If he confirms the functionality, I'll pick it up. I'll try to get it reviewed later this week.

Adrian

Hi Florian,
thanks for this series!

Without the maple port fix, this works as intended only when all four maple ports are populated. I am able to read from multiple VMUs in various slots.

However, with even one port not populated, it causes a panic:

Quoted 50 lines

Maple (null): detected Dreamcast Controller: function 0x1: at (0, 0) Maple (null): no driver found
Maple (null): detected Dreamcast Controller: function 0x1: at (1, 0) Maple (null): no driver found
Maple (null): detected Visual Memory: function 0xE: at (0, 1) Maple (null): no driver found

BUG: unable to handle kernel paging request at 00400000
PC: [<8c2aecee>] maple_send.part.0+0x102/0x1c8
Pgd = (ptrval)
[00400000] *pgd=00000000
Oops: 0000 [#1]
Modules linked in:

CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.18.0-rc5-next-20251114-00003-gb6bcd2e803f3 #25 PREEMPT
Workqueue: even maple_dma_handler (events)
PC is at maple_send.part.0+0x102/0x1c8
PR is at maple_send.part.0+0x5c/0x1c8

PC : 8c2aecee SP : 8c85bef8 SR : 40008000 TEA : 00400000 R0 : 0000002c R1 : 003fffc4 R2 : 00400004 R3 : 8c4e3d18 R4 : 8c92c024 R5 : 8c4e3d18 R6 : 0000002b R7 : 8c92c030 R8 : 00000000 R9 : 8c4e3d18 R10 : 00000016 R11 : 8c6aacdc R12 : 00000007 R13 : 8c914c20 R14 : 8c92c030
MACH: 00000001 MACL: 000006cc GBR : 8c000000 PR : 8c2aec48

Call trace:
 [<8c030c50>] process_one_work+0x114/0x290
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c3dac3a>] schedule+0x22/0x108
 [<8c03144a>] worker_thread+0x27e/0x3bc
 [<8c030b3c>] process_one_work+0x0/0x290
 [<8c0379c2>] kthread+0xde/0x1c0
 [<8c0311cc>] worker_thread+0x0/0x3bc
 [<8c0374fc>] to_kthread+0x0/0x1c
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c00f200>] ret_from_kernel_thread+0xc/0x14
 [<8c00b698>] arch_local_save_flags+0x0/0x8
 [<8c0418b0>] schedule_tail+0x0/0x78
 [<8c0378e4>] kthread+0x0/0x1c0

Process: kworker/0:1 (pid: 11, stack limit = (ptrval))

Stack: (0x8c85bef8 to 0x8c85c000)

Bee0: 8c030c50 8c00b6a0
Bf00: 8c80817c 8c808105 8c8462c0 8c808100 8c4e3d38 8c846280 00000000 48f0d9a1
Bf20: 8c3dac3a 8c85bf40 8c846280 00000000 8c03144a 8c8462c0 8c846280 8c4ca36c
Bf40: 8c8462a8 8c4da400 8c4ca388 8c030b3c 8c857ebc 8c80797c 8c0379c2 8c846280
Bf60: 8c0311cc 8c0374fc 8c857ebc 8c00b6a0 8c807960 8c805b40 00000000 8c85bf98
Bf80: 48f0d9a1 8c00f200 8c839f08 8c4dbbd8 8c493688 8c82c77c 8c00b698 00000000
Bfa0: 8c0418b0 00000000 00000000 00000000 00000000 8c805b40 8c0378e4 00000000
Bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Bfe0: 00000000 00000000 00000000 40008000 00000000 00000000 00000000 00000000

Quoted 1 line
---[ end trace 0000000000000000 ]---

This means we can't apply this series without the maple fix, and as such I'll recommend that this waits until hotplug is fixed.

PS. I don't know if it's down to the same issue, but once I remove and re-attach a VMU, it cannot be read from anymore:

Quoted 1 line

Dreamcast_visual_memory 0:01.E: VMU at (0, 1) is busy

PS. Adding Paul in the CC, he might be interested to test in the future.

Cheers,
Artur

author
#6 lore raw
Quoted 107 lines · Artur Rojek
Quoted 30 lines · John Paul Adrian Glaubitz

Hi Florian,

Quoted 11 lines · Florian Fuchs

This small series fixes build and runtime errors in the vmu-flash driver
(enabled by CONFIG_MTD_VMU) and the included maple.h. These changes were
verified on real Dreamcast hardware with a physical VMU. The VMU can now
be successfully probed, read and written with MTD tools like mtd_info and
mtd_debug. Previously, the driver failed to build or crashed during probing.

Quoted 11 lines

bash-5.3# mtdinfo /dev/mtd0
mtd0
Name: vmu2.1.0
Type: mlc-nand
Eraseblock size: 512 bytes
Amount of eraseblocks: 256 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 512 bytes
Sub-page size: 512 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true

Thanks again for this series. Before this can be picked up, I would like again
Artur Rojek to test it on his Dreamcast, so let's loop him in.

Quoted 5 lines

If he confirms the functionality, I'll pick it up. I'll try to get it reviewed
later this week.

Adrian

Hi Florian,
thanks for this series!

Without the maple port fix, this works as intended only when all four maple ports are populated. I am able to read from multiple VMUs in various slots.

However, with even one port not populated, it causes a panic:

Quoted 60 lines

Maple (null): detected Dreamcast Controller: function 0x1: at (0, 0) Maple (null): no driver found
Maple (null): detected Dreamcast Controller: function 0x1: at (1, 0) Maple (null): no driver found
Maple (null): detected Visual Memory: function 0xE: at (0, 1) Maple (null): no driver found

BUG: unable to handle kernel paging request at 00400000
PC: [<8c2aecee>] maple_send.part.0+0x102/0x1c8
Pgd = (ptrval)
[00400000] *pgd=00000000
Oops: 0000 [#1]
Modules linked in:

CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted
6.18.0-rc5-next-20251114-00003-gb6bcd2e803f3 #25 PREEMPT
Workqueue: even maple_dma_handler (events)
PC is at maple_send.part.0+0x102/0x1c8
PR is at maple_send.part.0+0x5c/0x1c8

PC : 8c2aecee SP : 8c85bef8 SR : 40008000 TEA : 00400000 R0 : 0000002c R1 : 003fffc4 R2 : 00400004 R3 : 8c4e3d18 R4 : 8c92c024 R5 : 8c4e3d18 R6 : 0000002b R7 : 8c92c030 R8 : 00000000 R9 : 8c4e3d18 R10 : 00000016 R11 : 8c6aacdc R12 : 00000007 R13 : 8c914c20 R14 : 8c92c030
MACH: 00000001 MACL: 000006cc GBR : 8c000000 PR : 8c2aec48

Call trace:
 [<8c030c50>] process_one_work+0x114/0x290
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c3dac3a>] schedule+0x22/0x108
 [<8c03144a>] worker_thread+0x27e/0x3bc
 [<8c030b3c>] process_one_work+0x0/0x290
 [<8c0379c2>] kthread+0xde/0x1c0
 [<8c0311cc>] worker_thread+0x0/0x3bc
 [<8c0374fc>] to_kthread+0x0/0x1c
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c00f200>] ret_from_kernel_thread+0xc/0x14
 [<8c00b698>] arch_local_save_flags+0x0/0x8
 [<8c0418b0>] schedule_tail+0x0/0x78
 [<8c0378e4>] kthread+0x0/0x1c0

Process: kworker/0:1 (pid: 11, stack limit = (ptrval))

Stack: (0x8c85bef8 to 0x8c85c000)

Bee0: 8c030c50
8c00b6a0
Bf00: 8c80817c 8c808105 8c8462c0 8c808100 8c4e3d38 8c846280 00000000 48f0d9a1
Bf20: 8c3dac3a 8c85bf40 8c846280 00000000 8c03144a 8c8462c0 8c846280 8c4ca36c
Bf40: 8c8462a8 8c4da400 8c4ca388 8c030b3c 8c857ebc 8c80797c 8c0379c2 8c846280
Bf60: 8c0311cc 8c0374fc 8c857ebc 8c00b6a0 8c807960 8c805b40 00000000 8c85bf98
Bf80: 48f0d9a1 8c00f200 8c839f08 8c4dbbd8 8c493688 8c82c77c 8c00b698 00000000
Bfa0: 8c0418b0 00000000 00000000 00000000 00000000 8c805b40 8c0378e4 00000000
Bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Bfe0: 00000000 00000000 00000000 40008000 00000000 00000000 00000000 00000000

Quoted 1 line
---[ end trace 0000000000000000 ]---
Quoted 8 lines

This means we can't apply this series without the maple fix, and as such I'll recommend that this waits until hotplug is fixed.

PS. I don't know if it's down to the same issue, but once I remove and re-attach a VMU, it cannot be read from anymore:

Quoted 1 line

Dreamcast_visual_memory 0:01.E: VMU at (0, 1) is busy

PS. Adding Paul in the CC, he might be interested to test in the future.

Hi Artur, thanks for testing!

I am not sure if the errors you see are related to the changes. The fixes only make the VMU code compile at all. Without that, the build fails and it crashes instantly.

So I would say, it is an improvement to the status quo.

Regards,
Florian

#7 lore raw
Quoted 117 lines · Florian Fuchs
Quoted 107 lines · Artur Rojek
Quoted 30 lines · John Paul Adrian Glaubitz

Hi Florian,

Quoted 11 lines · Florian Fuchs

This small series fixes build and runtime errors in the vmu-flash driver
(enabled by CONFIG_MTD_VMU) and the included maple.h. These changes were
verified on real Dreamcast hardware with a physical VMU. The VMU can now
be successfully probed, read and written with MTD tools like mtd_info and
mtd_debug. Previously, the driver failed to build or crashed during probing.

Quoted 11 lines

bash-5.3# mtdinfo /dev/mtd0
mtd0
Name: vmu2.1.0
Type: mlc-nand
Eraseblock size: 512 bytes
Amount of eraseblocks: 256 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 512 bytes
Sub-page size: 512 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true

Thanks again for this series. Before this can be picked up, I would like again
Artur Rojek to test it on his Dreamcast, so let's loop him in.

Quoted 5 lines

If he confirms the functionality, I'll pick it up. I'll try to get it reviewed
later this week.

Adrian

Hi Florian,
thanks for this series!

Without the maple port fix, this works as intended only when all four maple ports are populated. I am able to read from multiple VMUs in various slots.

However, with even one port not populated, it causes a panic:

Quoted 60 lines

Maple (null): detected Dreamcast Controller: function 0x1: at (0, 0) Maple (null): no driver found
Maple (null): detected Dreamcast Controller: function 0x1: at (1, 0) Maple (null): no driver found
Maple (null): detected Visual Memory: function 0xE: at (0, 1) Maple (null): no driver found

BUG: unable to handle kernel paging request at 00400000
PC: [<8c2aecee>] maple_send.part.0+0x102/0x1c8
Pgd = (ptrval)
[00400000] *pgd=00000000
Oops: 0000 [#1]
Modules linked in:

CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted
6.18.0-rc5-next-20251114-00003-gb6bcd2e803f3 #25 PREEMPT
Workqueue: even maple_dma_handler (events)
PC is at maple_send.part.0+0x102/0x1c8
PR is at maple_send.part.0+0x5c/0x1c8

PC : 8c2aecee SP : 8c85bef8 SR : 40008000 TEA : 00400000 R0 : 0000002c R1 : 003fffc4 R2 : 00400004 R3 : 8c4e3d18 R4 : 8c92c024 R5 : 8c4e3d18 R6 : 0000002b R7 : 8c92c030 R8 : 00000000 R9 : 8c4e3d18 R10 : 00000016 R11 : 8c6aacdc R12 : 00000007 R13 : 8c914c20 R14 : 8c92c030
MACH: 00000001 MACL: 000006cc GBR : 8c000000 PR : 8c2aec48

Call trace:
 [<8c030c50>] process_one_work+0x114/0x290
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c3dac3a>] schedule+0x22/0x108
 [<8c03144a>] worker_thread+0x27e/0x3bc
 [<8c030b3c>] process_one_work+0x0/0x290
 [<8c0379c2>] kthread+0xde/0x1c0
 [<8c0311cc>] worker_thread+0x0/0x3bc
 [<8c0374fc>] to_kthread+0x0/0x1c
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c00f200>] ret_from_kernel_thread+0xc/0x14
 [<8c00b698>] arch_local_save_flags+0x0/0x8
 [<8c0418b0>] schedule_tail+0x0/0x78
 [<8c0378e4>] kthread+0x0/0x1c0

Process: kworker/0:1 (pid: 11, stack limit = (ptrval))

Stack: (0x8c85bef8 to 0x8c85c000)

Bee0: 8c030c50
8c00b6a0
Bf00: 8c80817c 8c808105 8c8462c0 8c808100 8c4e3d38 8c846280 00000000 48f0d9a1
Bf20: 8c3dac3a 8c85bf40 8c846280 00000000 8c03144a 8c8462c0 8c846280 8c4ca36c
Bf40: 8c8462a8 8c4da400 8c4ca388 8c030b3c 8c857ebc 8c80797c 8c0379c2 8c846280
Bf60: 8c0311cc 8c0374fc 8c857ebc 8c00b6a0 8c807960 8c805b40 00000000 8c85bf98
Bf80: 48f0d9a1 8c00f200 8c839f08 8c4dbbd8 8c493688 8c82c77c 8c00b698 00000000
Bfa0: 8c0418b0 00000000 00000000 00000000 00000000 8c805b40 8c0378e4 00000000
Bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Bfe0: 00000000 00000000 00000000 40008000 00000000 00000000 00000000 00000000

Quoted 1 line
---[ end trace 0000000000000000 ]---
Quoted 8 lines

This means we can't apply this series without the maple fix, and as such I'll recommend that this waits until hotplug is fixed.

PS. I don't know if it's down to the same issue, but once I remove and re-attach a VMU, it cannot be read from anymore:

Quoted 1 line

Dreamcast_visual_memory 0:01.E: VMU at (0, 1) is busy

PS. Adding Paul in the CC, he might be interested to test in the future.

Quoted 7 lines

Hi Artur, thanks for testing!

I am not sure if the errors you see are related to the changes. The fixes only make the VMU code compile at all. Without that, the build fails and it crashes instantly.

So I would say, it is an improvement to the status quo.

I wouldn't say that trading a compilation issue for a runtime crash is an improvement. It only shows that further works needs to be done before we can accept both the VMU and maple port fixes, and that both of them are connected.

That said, great work getting it this far. I am here if you need further debug. If you'd like, check out #linux-sh IRC channel on libera.chat, then we can brainstorm this further.

Cheers,
Artur

Quoted 3 lines

Regards,
Florian

author
#8 lore raw
Quoted 134 lines · Artur Rojek
Quoted 120 lines · Florian Fuchs
Quoted 112 lines · Artur Rojek
Quoted 30 lines · John Paul Adrian Glaubitz

Hi Florian,

Quoted 11 lines · Florian Fuchs

This small series fixes build and runtime errors in the vmu-flash driver
(enabled by CONFIG_MTD_VMU) and the included maple.h. These changes were
verified on real Dreamcast hardware with a physical VMU. The VMU can now
be successfully probed, read and written with MTD tools like mtd_info and
mtd_debug. Previously, the driver failed to build or crashed during probing.

Quoted 11 lines

bash-5.3# mtdinfo /dev/mtd0
mtd0
Name: vmu2.1.0
Type: mlc-nand
Eraseblock size: 512 bytes
Amount of eraseblocks: 256 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 512 bytes
Sub-page size: 512 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true

Thanks again for this series. Before this can be picked up, I would like again
Artur Rojek to test it on his Dreamcast, so let's loop him in.

Quoted 5 lines

If he confirms the functionality, I'll pick it up. I'll try to get it reviewed
later this week.

Adrian

Hi Florian,
thanks for this series!

Without the maple port fix, this works as intended only when all four maple ports are populated. I am able to read from multiple VMUs in
various slots.

However, with even one port not populated, it causes a panic:

Quoted 60 lines

Maple (null): detected Dreamcast Controller: function 0x1: at (0, 0) Maple (null): no driver found
Maple (null): detected Dreamcast Controller: function 0x1: at (1, 0) Maple (null): no driver found
Maple (null): detected Visual Memory: function 0xE: at (0, 1) Maple (null): no driver found

BUG: unable to handle kernel paging request at 00400000
PC: [<8c2aecee>] maple_send.part.0+0x102/0x1c8
Pgd = (ptrval)
[00400000] *pgd=00000000
Oops: 0000 [#1]
Modules linked in:

CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted
6.18.0-rc5-next-20251114-00003-gb6bcd2e803f3 #25 PREEMPT
Workqueue: even maple_dma_handler (events)
PC is at maple_send.part.0+0x102/0x1c8
PR is at maple_send.part.0+0x5c/0x1c8

PC : 8c2aecee SP : 8c85bef8 SR : 40008000 TEA : 00400000 R0 : 0000002c R1 : 003fffc4 R2 : 00400004 R3 : 8c4e3d18 R4 : 8c92c024 R5 : 8c4e3d18 R6 : 0000002b R7 : 8c92c030 R8 : 00000000 R9 : 8c4e3d18 R10 : 00000016 R11 : 8c6aacdc R12 : 00000007 R13 : 8c914c20 R14 : 8c92c030
MACH: 00000001 MACL: 000006cc GBR : 8c000000 PR : 8c2aec48

Call trace:
 [<8c030c50>] process_one_work+0x114/0x290
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c3dac3a>] schedule+0x22/0x108
 [<8c03144a>] worker_thread+0x27e/0x3bc
 [<8c030b3c>] process_one_work+0x0/0x290
 [<8c0379c2>] kthread+0xde/0x1c0
 [<8c0311cc>] worker_thread+0x0/0x3bc
 [<8c0374fc>] to_kthread+0x0/0x1c
 [<8c00b6a0>] arch_local_irq_restore+0x0/0x24
 [<8c00f200>] ret_from_kernel_thread+0xc/0x14
 [<8c00b698>] arch_local_save_flags+0x0/0x8
 [<8c0418b0>] schedule_tail+0x0/0x78
 [<8c0378e4>] kthread+0x0/0x1c0

Process: kworker/0:1 (pid: 11, stack limit = (ptrval))

Stack: (0x8c85bef8 to 0x8c85c000)

Bee0: 8c030c50
8c00b6a0
Bf00: 8c80817c 8c808105 8c8462c0 8c808100 8c4e3d38 8c846280 00000000 48f0d9a1
Bf20: 8c3dac3a 8c85bf40 8c846280 00000000 8c03144a 8c8462c0 8c846280 8c4ca36c
Bf40: 8c8462a8 8c4da400 8c4ca388 8c030b3c 8c857ebc 8c80797c 8c0379c2 8c846280
Bf60: 8c0311cc 8c0374fc 8c857ebc 8c00b6a0 8c807960 8c805b40 00000000 8c85bf98
Bf80: 48f0d9a1 8c00f200 8c839f08 8c4dbbd8 8c493688 8c82c77c 8c00b698 00000000
Bfa0: 8c0418b0 00000000 00000000 00000000 00000000 8c805b40 8c0378e4 00000000
Bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Bfe0: 00000000 00000000 00000000 40008000 00000000 00000000 00000000 00000000

Quoted 1 line
---[ end trace 0000000000000000 ]---

This means we can't apply this series without the maple fix, and as such
I'll recommend that this waits until hotplug is fixed.

Quoted 6 lines

PS. I don't know if it's down to the same issue, but once I remove and re-attach a VMU, it cannot be read from anymore:

Quoted 1 line

Dreamcast_visual_memory 0:01.E: VMU at (0, 1) is busy

PS. Adding Paul in the CC, he might be interested to test in the future.

Quoted 7 lines

Hi Artur, thanks for testing!

I am not sure if the errors you see are related to the changes. The fixes only make the VMU code compile at all. Without that, the build fails and it crashes instantly.

So I would say, it is an improvement to the status quo.

I wouldn't say that trading a compilation issue for a runtime crash is an improvement. It only shows that further works needs to be done before we can accept both the VMU and maple port fixes, and that both of them are connected.

Quoted 10 lines

That said, great work getting it this far. I am here if you need further debug. If you'd like, check out #linux-sh IRC channel on libera.chat, then we can brainstorm this further.

Cheers,
Artur

Quoted 3 lines

Regards,
Florian

I mean, I guess it's ok, as the code is like this for a long time, so it should be alright, when it keeps like this for a few weeks now, until an extensive fix. I just sent it now for a gradual improvement, in my opinion, as I need to invest a bit more debugging for the maple misbehaviour than for the obvious build breakage.

Thank you for your kind words, I don't take them for granted! And I will certainly hang around in #linux-sh as I have a few other things there to debug were I really need some additional input.

see you there,
Florian

maintainer
#9 lore raw

Hi Florian,

Quoted 5 lines · Florian Fuchs

I mean, I guess it's ok, as the code is like this for a long time, so it should be alright, when it keeps like this for a few weeks now, until an extensive fix. I just sent it now for a gradual improvement, in my opinion, as I need to invest a bit more debugging for the maple misbehaviour than for the obvious build breakage.

Thank you for your patience. I hope that you don't read Artur's recommendation as a general dismissal of your work because it's not meant that way.

It's highly appreciated that you are stepping up to work on the Dreamcast code and I will absolutely be happy to pick up your patches once the runtime checks are positive and Artur is satisfied as well.

It's perfectly normal that some patch series can take several rounds until everyone is happy. But it's usually worth the effort and you will also be able to learn from others.

Quoted 3 lines

Thank you for your kind words, I don't take them for granted! And I will certainly hang around in #linux-sh as I have a few other things there to debug were I really need some additional input.

Really looking forward to this! A warm welcome to the SH community ;-).

Adrian

Signature · 4 lines
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913