From: Shawn Lin <shawn.lin@rock-chips.com>
To: Ulf Hansson <ulfh@kernel.org>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
Shawn Lin <shawn.lin@linux.dev>,
Shawn Lin <shawn.lin@rock-chips.com>
Subject: [PATCH v2 0/3] Add SDIO userspace passthrough support
Date: Mon, 21 Sep 2026 15:18:16 +0800 [thread overview]
Message-ID: <1789975099-157594-1-git-send-email-shawn.lin@rock-chips.com> (raw)
SDIO cards are normally driven by function drivers (brcmfmac,
mwifiex, rtw88_8723bs, ...), but bring-up, debugging and factory
test frequently need to poke the SDIO register space directly:
CCCR/FBR in function 0, or vendor registers before any function
driver is bound, and some deployments, notably lightweight IoT
boards, want to handle the SDIO function entirely from userspace.
Today the only way is to write a tiny kernel driver per device.
So this series adds raw userspace access to the SDIO register
space as well a small reference client. Meanwhile, adding a new
documentation about how to write a proper SDIO function driver,
because I have recently been working on SDIO function drivers
and kept referring to the existing drivers for guidance. It turns
out that the knowledge is scattered and there is no unified document
describing how an SDIO function driver is supposed to be written,
despite the MMC core having clear expectations about how the APIs
are used.
In particular, the interrupt model has many pitfalls:
sdio_claim_irq()/sdio_release_irq() must be called with the host
claimed, the handler runs with the host already claimed and must
not sleep or claim the bus itself, and sdio_release_irq() must be
called from ->remove() because it is the last chance before the
core removes the function devices from mmc_remove_host(). Recent
fixes around the SDIO IRQ work and host removal and the discussions
on the mailing list showed how easily these contracts get broken.
Also worth documenting is the buffer requirement of the CMD53 based
helpers: the core builds a scatterlist directly from the caller's
buffer and the host driver maps it for DMA, so vmalloc() or stack
allocated buffers are not acceptable, while the CMD52 byte accessors
are safe with stack buffers.
Changes-in-v2:
- drop RFC as I don't include mmc-utils to be sdio usersapce tool
- add sdio doc
Shawn Lin (3):
mmc: core: Add SDIO userspace passthrough character device
tools/sdio: add sdio-raw userspace client
docs: mmc: add introduction to writing SDIO function drivers
Documentation/driver-api/mmc/index.rst | 1 +
.../driver-api/mmc/sdio-function-drivers.rst | 211 ++++++
MAINTAINERS | 2 +
drivers/mmc/Kconfig | 11 +
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/sdio_bus.c | 12 +-
drivers/mmc/core/sdio_cdev.c | 189 ++++++
drivers/mmc/core/sdio_cdev.h | 21 +
include/linux/mmc/sdio_func.h | 4 +
include/uapi/linux/mmc/sdio_ioctl.h | 48 ++
tools/Makefile | 14 +-
tools/sdio/Build | 1 +
tools/sdio/Makefile | 66 ++
tools/sdio/gen-sdio-ids.sh | 59 ++
tools/sdio/sdio-raw.c | 714 +++++++++++++++++++++
15 files changed, 1346 insertions(+), 8 deletions(-)
create mode 100644 Documentation/driver-api/mmc/sdio-function-drivers.rst
create mode 100644 drivers/mmc/core/sdio_cdev.c
create mode 100644 drivers/mmc/core/sdio_cdev.h
create mode 100644 include/uapi/linux/mmc/sdio_ioctl.h
create mode 100644 tools/sdio/Build
create mode 100644 tools/sdio/Makefile
create mode 100644 tools/sdio/gen-sdio-ids.sh
create mode 100644 tools/sdio/sdio-raw.c
--
2.7.4
next reply other threads:[~2026-09-21 8:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 7:18 Shawn Lin [this message]
2026-09-21 7:18 ` [PATCH v2 1/3] mmc: core: Add SDIO userspace passthrough character device Shawn Lin
2026-09-21 7:18 ` [PATCH v2 2/3] tools/sdio: add sdio-raw userspace client Shawn Lin
2026-09-21 7:18 ` [PATCH v2 3/3] docs: mmc: add introduction to writing SDIO function drivers Shawn Lin
2026-10-29 0:27 ` [PATCH v2 0/3] Add SDIO userspace passthrough support Shawn Lin
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=1789975099-157594-1-git-send-email-shawn.lin@rock-chips.com \
--to=shawn.lin@rock-chips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=shawn.lin@linux.dev \
--cc=ulfh@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
all inboxes | Powered by JetHome®