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
| ||
|
Date: Mon, 09 Aug 2010 09:56:04 +0300 From: Maxim Levitsky <maximlevitsky@...il.com> To: Alex Dubov <oakad@...oo.com> Cc: LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader. On Sun, 2010-08-08 at 23:31 -0700, Alex Dubov wrote: > > > > 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). Ok, maybe I didn't explain myself correctly. Device is in serial mode. I set need_card_int I send a command. <here I assume that driver waits for CED bit, which is exposed on data line, if CED won't be set, driver/hardware will timeout> I send GET_INT _once_, look at flags. If I see CED, no NACK, then ok, otherwise I send error result. > > > > > 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. I suspect that managment flag also has default value of 0xFF, and these 'special' features (drm, boot block, temporary table) clear bits out of it. > > > > > > > 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. That I understand clearly. I ask what the meaning of MEMSTICK_INT_ERR is. I expect it to be set if any of (un) correctable errors are found. Therefore if MEMSTICK_INT_ERR, I can't report error instantly, but I need to look at status1 to see if error is correctable or not. This is correct? Best regards, Maxim Levitsky -- 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/
Powered by blists - more mailing lists