Some MMC hosts can only handle log2 block sizes.  Unfortunately,
the MMC password support needs to be able to send non-log2 block
sizes.  Provide a capability so that the MMC password support can
decide whether it should use this support or not.

The unfortunate side effect of this host limitation is that any
MMC card protected by a password which is not a log2 block size
can not be accessed on a host which only allows a log2 block size.

This change just adds the flag.  The MMC password support code
needs updating to use it (if and when it is finally submitted.)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add a capability flag for drivers to set when they can perform multi-
block transfers to cards _and_ correctly report the number of bytes
transferred should an error occur.

The last point is very important - if a driver reports more bytes than
were actually accepted by the card and an error occurs, there is the
possibility for data loss.

Pierre Ossman provided the patch for wbsd and sdhci.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Let drivers constify MMC host method operations tables,
moving them from ".data" to ".rodata".
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

mmc_priv() has some nasty effects if the wrong pointer type is
passed to it.  Introduce type checking, which also means we get
the right type.  Also add an additional member to mmc_host which
is used to align host-private data appropriately.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Change mmc_detect_change() to take a delay argument such that
the detection of card insertions and removals can be delayed
according to the requirements of the host driver or platform.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Infrastructure for 4-bit bus transfers with SD cards.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Support for the read-only switch on SD cards which must be enforced by the
host.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NPierre Ossman <drzeus@drzeus.cx>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Adds a new ios for setting the chip select pin on MMC cards. Needed on
SD controllers which use this pin for other things and therefore cannot
have it pulled high at all times.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There's no point in having the host name duplicated between
the mmc_host structure and the encapsulated class device
structure.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Create a mmc_host class to allow enumeration of MMC host controllers
even though they have no card(s) inserted.

Patch based on work by Pierre Ossman.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

mmc_hostname() returns a pointer to the hostname for the mmc_host.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This fixes u32 vs.  pm_message_t confusion in remaining places.  Fortunately
there's few of them.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!