On Wed, Dec 14, 2005 at 09:30:49AM -0400, Anderson Briglia wrote:
> /*
> - * This currently matches any MMC driver to any MMC card - drivers
> - * themselves make the decision whether to drive this card in their
> - * probe method. However, we force "bad" cards to fail.
> + * This currently matches any MMC driver to any MMC card - drivers themselves
> + * make the decision whether to drive this card in their probe method. However,
> + * we force "bad" cards to fail.
> + *
> + * We also fail for all locked cards; drivers expect to be able to do block I/O
> + * still on probe(), which is not possible while the card is locked. Device
> + * probing must be triggered sometime later to make the card available to the
> + * block driver.
> */
Please arrange comments to wrap _before_ the last column, as per the
original.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Wed, Dec 14, 2005 at 09:30:49AM -0400, Anderson Briglia wrote:
> @@ -69,12 +70,16 @@ struct mmc_card {
> #define mmc_card_bad(c) ((c)->state & MMC_STATE_BAD)
> #define mmc_card_sd(c) ((c)->state & MMC_STATE_SDCARD)
> #define mmc_card_readonly(c) ((c)->state & MMC_STATE_READONLY)
> +#define mmc_card_locked(c) ((c)->state & MMC_STATE_LOCKED)
> +
> +#define mmc_card_lockable(c) ((c)->csd.cmdclass & CCC_LOCK_CARD)
Looking at some of the MMC specs, this is not sufficient to tell whether
the card supports the lock/unlock commands - eg, the Sandisk cards have
a CCC value of 0x1ff but do not appear to support CMD42.
It would appear that there are different definitions for command
classes 6 to 8:
command group: A B
6 write write-protection write protection
7 read write-protection lock card
8 erase write-protection app. specific
What the interpretation of whether A or B applies is unclear.
Type A cards have CSD structure 1 and MMC protocol version code 1.
Type B cards have CSD structure 2 and MMC protocol version code 3.
It would appear that the "CSD structure" field describes the version
of the CSD structure itself, and in part determines the validity
of the MMC protocol version field (maybe defining the mapping of
version codes to MMC spec versions). Sandisk implies that CSD
structure 1 has version codes 0=v1.0-v1.2, 1=v1.4.
CSD structure 2 we have less idea about the interpretation of the
MMC protocol version codes, except that 3 may mean MMC spec v3.1.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core