public inbox for linux-sh@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Fuchs <fuchsfl@gmail.com>
To: linux-sh@vger.kernel.org,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Rich Felker <dalias@libc.org>,
	Artur Rojek <contact@artur-rojek.eu>
Cc: Adrian McMenamin <adrianmcmenamin@gmail.com>,
	linux-kernel@vger.kernel.org, Florian Fuchs <fuchsfl@gmail.com>
Subject: [PATCH v2] sh: maple: fix empty port handling
Date: Sun, 26 Apr 2026 23:27:14 +0200	[thread overview]
Message-ID: <20260426212714.2286437-1-fuchsfl@gmail.com> (raw)

Fix the handling of empty ports, to restore the ability to use the device
with less than 4 populated ports and also be able to hot-plug new devices
in empty ports at runtime.

Explicitly cast the response code in maple_response_devinfo() to s8 so
that 0xFF from the device gets interpreted as signed and flows like the
NONE response, previously it was considered unknown response code, which
blocked the maple bus.

Remove the locking variable from maple_vblank_handler() as there is no
locking information returned from maple_add_packet() and it lead to only
ever check exactly one empty port.

Update maple_response_devinfo() to explicitly check for empty ports on
unit 0, to be able to hot-plug devices in empty ports.

Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
---
v1->v2: Don't break hot-plugging of new devices to empty ports.
	Explicitly cast the response code to s8 to use the existing
	logic, that relies on signed chars. In the case of 0xff (all 1s,
	DCs TIMEOUT response) that was interpreted as 255 unknown response
	code, which blocked the maple bus, as busy was never reset. Add
	condition to maple_response_devinfo() to process the devinfo 
	for currently empty ports.

v1: https://lore.kernel.org/all/20251112190444.3631533-1-fuchsfl@gmail.com/

Note that the removal of peripherals is possible, the ports get marked as
empty, but the driver is never detached. That means a peripheral can be
removed, but the port keeps "reserved" for this peripheral and can't be
reused with another peripheral.

VMUs can't be removed at runtime, as MTD keeps a reference to it, so that
mdev->can_unload() is never true. But the same peripheral can be
inserted to the same port again.

 drivers/sh/maple/maple.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index 5585f220e495..8e7bb42aef07 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -445,7 +445,7 @@ static int setup_maple_commands(struct device *device, void *ignored)
 /* VBLANK bottom half - implemented via workqueue */
 static void maple_vblank_handler(struct work_struct *work)
 {
-	int x, locking;
+	int x;
 	struct maple_device *mdev;
 
 	if (!maple_dma_done())
@@ -474,13 +474,10 @@ static void maple_vblank_handler(struct work_struct *work)
 				if (!mdev)
 					break;
 				atomic_set(&mdev->busy, 1);
-				locking = maple_add_packet(mdev, 0,
+				maple_add_packet(mdev, 0,
 					MAPLE_COMMAND_DEVINFO, 0, NULL);
-				if (!locking)
-					break;
-				}
 			}
-
+		}
 		maple_pnp_time = jiffies + MAPLE_PNP_INTERVAL;
 	}
 
@@ -578,7 +575,8 @@ static void maple_response_devinfo(struct maple_device *mdev,
 				   char *recvbuf)
 {
 	char submask;
-	if (!started || (scanning == 2) || !fullscan) {
+	if (!started || (scanning == 2) || !fullscan ||
+	    ((mdev->unit == 0) && empty[mdev->port])) {
 		if ((mdev->unit == 0) && (checked[mdev->port] == false)) {
 			checked[mdev->port] = true;
 			maple_attach_driver(mdev);
@@ -644,7 +642,7 @@ static void maple_dma_handler(struct work_struct *work)
 			recvbuf = mq->recvbuf->buf;
 			__flush_invalidate_region(sh_cacheop_vaddr(recvbuf),
 					0x400);
-			code = recvbuf[0];
+			code = (s8)recvbuf[0];
 			kfree(mq->sendbuf);
 			list_del_init(&mq->list);
 			switch (code) {

base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
-- 
2.43.0


                 reply	other threads:[~2026-04-26 22:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260426212714.2286437-1-fuchsfl@gmail.com \
    --to=fuchsfl@gmail.com \
    --cc=adrianmcmenamin@gmail.com \
    --cc=contact@artur-rojek.eu \
    --cc=dalias@libc.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox