All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Dubov <oakad@yahoo.com>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.
Date: Sun, 8 Aug 2010 23:31:31 -0700 (PDT)	[thread overview]
Message-ID: <397573.48417.qm@web37608.mail.mud.yahoo.com> (raw)
In-Reply-To: <1281298140.10030.96.camel@maxim-laptop>

> 
> I currently assume that if I set req->need_card_int, the
> driver will
> wait till device raises MEMSTICK_INT_CED regardless of
> serial/parallel
> mode. This bit is always available on serial line.
> Is that OK to assume?

I'm not quite sure about this question.
Normally, when you wait for the media interrupt, you want to see the whole
value of the INT register (CED by itself doesn't indicate successful
command completion; in fact it's value is undefined in presence of other
INT flags, like BREQ or CMDNK). In parallel mode, host is required to
fetch all meaningful INT bits from the media bus, while in serial mode
this is only possible, if host supports automatic INT retrieval (the host
will issue GET_INT tpc behind the scenes before alerting the software).

> 
> Another thing that I want to ask is about writes to
> overwrite/managment
> flag.
> Common sense tells me that I can write the flash many
> times, but write
> can only clear bits. Therefore if I write 0xFF, this just
> means do
> nothing.
> Probably same applies to data content, but that isn't much
> of the use.

Yes, all memsticks are NAND flash, so writing 1s has no effect whatsoever.

> Thats why I see that default (good) value of bits in
> overwrite flag is
> 1.
> This is correct I assume?

Yes, a direct consequence of the above.

> 
> 
> Another interesting thing I observed was that
> MEMSTICK_INT_ERR can mean
> a correctable error,  therefore it shouldn't
> alone  reject read/write of
> a sector. (I think that it means that one of
> MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set)
> Same question about this.
> 

There are three groups of error flags. While overwrite_flag register is
accessible as part of extra data, being the indicator of block goodness
it earned its own error flag:

DTER (UCDT) - error (uncorrectable) in data area
EXER (UCEX) - error (uncorrectable) in extra data area
FGER (UCFG) - error (uncorrectable) in overwrite_flag register

Uncorrectable error means that you've got some bit errors in the data
you've obtained from the media. If uncorrectable flag is not set, it
means that media's ECC circuit managed to correct the bit flip. The
desired way of action is, of course, to reallocate the block before it
develops an uncorrectable failure.



      

  reply	other threads:[~2010-08-09  6:31 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05  8:30 [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader Alex Dubov
2010-08-05 11:20 ` Maxim Levitsky
2010-08-05 11:48   ` Alex Dubov
2010-08-05 12:30     ` Maxim Levitsky
2010-08-05 17:47       ` Maxim Levitsky
2010-08-06  7:43         ` Alex Dubov
2010-08-06 10:56           ` Maxim Levitsky
2010-08-07 13:15             ` Alex Dubov
2010-08-07 15:58               ` Maxim Levitsky
2010-08-08 13:31                 ` Alex Dubov
2010-08-06  8:01       ` Alex Dubov
2010-08-05 12:46 ` Maxim Levitsky
2010-08-06  7:59   ` Alex Dubov
2010-08-06 10:59     ` Maxim Levitsky
2010-08-07 13:12       ` Alex Dubov
2010-08-07 16:03         ` Maxim Levitsky
2010-08-08 13:33           ` Alex Dubov
2010-08-07 20:22 ` Maxim Levitsky
2010-08-08 14:26   ` Alex Dubov
2010-08-08 15:07     ` Maxim Levitsky
2010-08-08 20:08       ` Maxim Levitsky
2010-08-09  6:31         ` Alex Dubov [this message]
2010-08-09  6:56           ` Maxim Levitsky
2010-08-09 15:30           ` Maxim Levitsky
2010-08-10  8:12             ` Alex Dubov
2010-08-10  9:47               ` Maxim Levitsky
2010-08-11  8:08                 ` Alex Dubov
2010-08-11  8:32                   ` Maxim Levitsky
2010-08-12  7:22                     ` Alex Dubov
2010-08-12  7:58                       ` Maxim Levitsky
2010-08-12  7:27                     ` JMicron chipset update Alex Dubov
2010-08-09 19:19           ` [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader Maxim Levitsky
2010-08-10  7:53             ` Alex Dubov
2010-08-10  9:50               ` Maxim Levitsky
2010-08-11  8:16                 ` Alex Dubov
  -- strict thread matches above, loose matches on Subject: below --
2010-12-09  2:39 MEMSTICK: Add my 2 drivers Maxim Levitsky
2010-12-09  2:42 ` [PATCH 2/2] memstick: Add driver for Ricoh R5C592 card reader Maxim Levitsky
2010-08-03 14:53 [PATCH 0/2] Driver for Ricoh cardreader Maxim Levitsky
2010-08-03 14:53 ` [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader Maxim Levitsky
2010-08-04  7:57   ` Alex Dubov
2010-08-04 16:48     ` Maxim Levitsky
2010-08-04 19:31       ` Maxim Levitsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=397573.48417.qm@web37608.mail.mud.yahoo.com \
    --to=oakad@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.