linux-kernel - MMC host driver requirements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 7 Sep 2008 23:52:28 +0200
From:	Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:	linux-kernel@...r.kernel.org
Cc:	drzeus-mmc@...eus.cx, oakad@...oo.com
Subject: MMC host driver requirements

Hello,

I'm writing a driver for ENE CB710/720 memory card readers found in some
laptops (ie. some versions of HP Compaq nx9500). This chip has three
memory card interfaces: MMC/SD, SmartMedia, MemoryStick. I started with
the MMC interface as I have a card to test it with, but I could not find
any documentation about MMC stack besides the source code.

So here are some questions:

1. Can I call mmc_detect_change() after mmc_alloc_host() but before or
   during mmc_add_host() (ie. from interrupt handler)? If yes, what
   if mmc_alloc_host() fails then?
2. Can I call mmc_request_done() from ->request() handler?
3. Does MMC stack serialize calls to ->request() or any other host
   driver ops?
4. What is the difference (if any) between mrq->data and mrq->cmd->data
   as seen from ->request()?
5. Are there any constraints to scatterlist passed to ->request()
   - number of elements, data alignment, element data size?
   (At first I assumed that there are none and have writted a simple
   wrapper to guarantee multiple-of-16-byte data blocks - but maybe
   its just not needed?)

If/when I finish the driver there is the question what are the
requirements for it to be accepted to mainline? It's based on
reverse-engineering work on a Windows driver so it will have
some magic register-access sequences, as the original driver used
completely different MMC/SD stack and probably not fully used chip's
capabilities.

BTW, Google said nothing interesting about the hardware: most hits are
about not existing drivers for it and manufacturer ignoring inquiries
for datasheets.

Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/