linux-kernel - Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <397573.48417.qm@web37608.mail.mud.yahoo.com>
Date:	Sun, 8 Aug 2010 23:31:31 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.

> 
> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/