I think the trivial fix will do (after all, there's nothing that should matter
to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I
can't test this.
--- tifm_sd.c.orig 2006-12-11 01:39:28.0 +1100
+++ tifm_sd.c 2007-01-04
I think the trivial fix will do (after all, there's nothing that should matter
to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I
can't test this.
--- tifm_sd.c.orig 2006-12-11 01:39:28.0 +1100
+++ tifm_sd.c 2007-01-04
Philip Langdale wrote:
> Pierre Ossman wrote:
>
>> Amen to that. All hw vendors that implement this particular form of
>> brain damage should be dragged out and shot.
>>
>> I'll fix a patch for this later on.
>>
>
> See my updated Take 3 patch. I've implemented a uniqueness fix by
> adding
Pierre Ossman wrote:
>
> Amen to that. All hw vendors that implement this particular form of
> brain damage should be dragged out and shot.
>
> I'll fix a patch for this later on.
See my updated Take 3 patch. I've implemented a uniqueness fix by
adding additional RSP flags do make R6 and R7
Philip Langdale wrote:
> This is a bug. The MMC_RSP_R? #defines do not fully characterise the
> responses (specically, the way that the response is parsed is not
> characterised) and consequently there is no guarantee of uniqueness.
> Given this reality - the way that the tifm_sd driver works is
Andrew Morton wrote:
> On Mon, 01 Jan 2007 07:29:55 -0800
> Philip Langdale <[EMAIL PROTECTED]> wrote:
>
>> #define MMC_RSP_R1B
>> (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
>> #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
>> #define MMC_RSP_R3
On Mon, 01 Jan 2007 07:29:55 -0800
Philip Langdale <[EMAIL PROTECTED]> wrote:
> #define MMC_RSP_R1B
> (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
> #define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
> #define MMC_RSP_R3 (MMC_RSP_PRESENT)
> -#define MMC_RSP_R6
Philip Langdale wrote:
> @@ -1386,10 +1420,37 @@
>* all get the idea that they should be ready for CMD2.
>* (My SanDisk card seems to need this.)
>*/
> - if (host->mode == MMC_MODE_SD)
> - mmc_send_app_op_cond(host, host->ocr, NULL);
> - else
> + if
Philip Langdale wrote:
@@ -1386,10 +1420,37 @@
* all get the idea that they should be ready for CMD2.
* (My SanDisk card seems to need this.)
*/
- if (host-mode == MMC_MODE_SD)
- mmc_send_app_op_cond(host, host-ocr, NULL);
- else
+ if (host-mode
On Mon, 01 Jan 2007 07:29:55 -0800
Philip Langdale [EMAIL PROTECTED] wrote:
#define MMC_RSP_R1B
(MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
#define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
#define MMC_RSP_R3 (MMC_RSP_PRESENT)
-#define MMC_RSP_R6
Andrew Morton wrote:
On Mon, 01 Jan 2007 07:29:55 -0800
Philip Langdale [EMAIL PROTECTED] wrote:
#define MMC_RSP_R1B
(MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE|MMC_RSP_BUSY)
#define MMC_RSP_R2 (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC)
#define MMC_RSP_R3 (MMC_RSP_PRESENT)
-#define
Philip Langdale wrote:
This is a bug. The MMC_RSP_R? #defines do not fully characterise the
responses (specically, the way that the response is parsed is not
characterised) and consequently there is no guarantee of uniqueness.
Given this reality - the way that the tifm_sd driver works is
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level
Thanks to the generous donation of an SDHC card by John Gilmore, and the
surprisingly enlightened decision by the SD Card Association to publish
useful specs, I've been able to bash out support for SDHC. The changes
are not too profound:
i) Add a card flag indicating the card uses block level
14 matches
Mail list logo
