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
12 matches
Mail list logo
