Commit Graph

7 Commits

Author SHA1 Message Date
Russell King 5bd546aa78 [MMC] Fix mmc_cmd_type() mask
It's MMC_CMD_MASK not MMC_CMD_TYPE.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-02-22 09:32:46 +00:00
Russell King e92251762d [MMC] Add MMC command type flags
Some hosts need to know the command type, so pass it via a set of
flags in cmd->flags.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-02-02 12:23:12 +00:00
Pierre Ossman 7225b3fd0b [MMC] Indicate that R1/R1b contains command opcode
Some controllers actually check the first byte of the response (most
don't).  This byte contains the command opcode for R1/R1b and all 1:s
for other types. The difference must be indicated to the controller
so it knows which reply to expect.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2006-01-09 22:51:46 +00:00
Russell King 788ee7b098 [MMC] Add DATA_MULTI flag
Some hosts need to know that a transfer will be multi-block.
Add a data flag to indicate multiple data block transfers.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-09 21:12:17 +00:00
Erik Hovland 8573b80f02 [ARM] 3031/1: fix typos in comments of mmc.h
Patch from Erik Hovland

I noticed that the same typo (i before c in associated) showed up twice
in the file kernel/include/linux/mmc/mmc.h.

This patch fixes both of the instances I found with this mistake. The
typos are in comments and should have no affect on working code.

E

Signed-off-by: Erik Hovland <erik@hovland.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-28 16:28:04 +01:00
Pierre Ossman 335eadf2ef [PATCH] sd: initialize SD cards
Support for the Secure Digital protocol in the MMC layer.

A summary of the legal issues surrounding SD cards, as understood by yours
truly:

Members of the Secure Digital Association, hereafter SDA, are required to sign
a NDA[1] before given access to any specifications.  It has been speculated
that including an SD implementation would forbid these members to redistribute
Linux.  This is the basic problem with SD support so it is unclear if it even
is a problem since it has no effect on those of us that aren't members.

The SDA doesn't seem to enforce these rules though since the patches included
here are based on documentation made public by some of the members.  The most
complete specs[2] are actually released by Sandisk, one of the founding
companies of the SDA.

Because of this the NDA is considered a non-issue by most involved in the
discussions concerning these patches.  It might be that the SDA is only
interested in protecting the so called "secure" bits of SD, which so far
hasn't been found in any public spec.  (The card is split into two sections,
one "normal" and one "secure" which has an access scheme similar to TPM:s).

(As a side note, Microsoft is working to make things easier for us since they
want to be able to include the source code for a SD driver in one of their
development kits.  HP is making sure that the new NDA will allow a Linux
implementation.  So far only the SDIO specs have been opened up[3].  More will
hopefully follow.)

 [1] http://www.sdcard.org/membership/images/ippolicy.pdf
 [2] http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf
 [3] http://www.sdcard.org/sdio/Simplified%20SDIO%20Card%20Specification.pdf

This patch contains the central parts of the SD support.  If no MMC cards are
found on a bus then the MMC layer proceeds looking for SD cards.  Helper
functions are extended to handle the special needs of SD cards.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:50 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00