mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


             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®