linux-kernel - Re: [PATCH 0/6] Results of my work on memorystick subsystem

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: <1287356101.25869.1.camel@maxim-laptop>
Date:	Mon, 18 Oct 2010 00:55:01 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Alex Dubov <oakad@...oo.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/6] Results of my work on memorystick subsystem

On Sun, 2010-10-17 at 01:12 +0200, Maxim Levitsky wrote:
> Hi,
> 
> Here is a result of lot of work I did improving the memorystick
> subsystem and its drivers.
Comments?
Flames?
Suggestions?

Best regards,
	Maxim Levitsky

> 
> patch #1 add common code to memorystick core that makes card drivers easier
> to understand
> 
> patch #2 just add a driver for my card reader
> 
> patch #3 reworks the Jmicron driver.
> I can write a novel about the problems I had to go through with this device
> (mostly hardware bugs I belive).
> So I refactored the driver and added a lot of debug output future users.
> Currently both MS and MSPro work fine.
> 
> patch #4 adds support for lagacy memorysticks.
> Everything just works, not a single corruption this far.
> 
> patch #5, is what I did recently.
> I rewrote large chunks on mspro_blk.c to use the common code I added in patch #1.
> I also added lot of debug code, comments.
> 
> patch #6 adds more cleanups.
> 
> Now register window changes are completely hidden and automatic.
> Functions that state machines call are explictly marked as so,
> and that assumption is tested.
> the card->current_mrq isn't passed as a pointer to functions
> as this just complicates the code.
> 
> Code is tested with 2 mspro cards and one MS card.
> 
> Thanks again to Alex for his work.
> 
> ***Changes from V1 ***
> 
> * Fixed brown paper bug in memstick core.
> memset had its 2 and 3 arguments swapped.
> 
> * Cleaned a lot the PIO code in my r592 driver.
> Now it finally looks sane.
> Also tested it throughfully.
> 
> * Endiannes fixes in Jmicron driver and r592
> 
> Best regards,
> 	Maxim Levitsky
> 
> ***Appendix***
> 
> Jmicron hardware bugs (the novel):
> 
> #1: FIFO write ready bit in INT status register is stuck to 1.
>    It is stuck forever as soon as fifo
>    is used for writing even once.
>    Therefore if interrupt is shared (and here it is), its easy
>    to 'service' the device while it doesn't need any service
> 
> 
> #2: Its not possible to stuff the FIFO before TPC transfer.
>    One really have to wait for write ready interrupt, even though the write ready status is stuck.
> 
> 
> #3: TPCs with non 4 aligned length woes:
>    Facts:
> 
>    * non 4 aligned DMA write hangs the system hard, maybe on bus level.
> 
>    * PIO read succedes but controller truncates the data stored in the FIFO to closest 4 byte boundary.
>    That is if you read 26 bytes, it will save 24 bytes in the FIFO
> 
>    * PIO non-aligned write work, expect that they sometimes hose the DMA.... (regardless of the alignment)
> 
>    * TPC_P0, TPC_P1 not aligned transfters work just fine despite a statement in the datasheet
>    that they are undefined.... (only mention of this problem)
> 
> 
> #4: As soon as write PIO is used, then later write DMA fails.
>    Facts:
> 
>    * This is triggered only by PIO write of registers
>    (only happens in ms_block.c when it writes param + oob. Thats why mspro_blk isn't affected)
>    Doing short DMA writes is a nice workaround.
> 
>    * Doing PIO writes in h_msb_read_page don't cause the problem.
>      Therefore the bug causing sequence should be similiar to h_msb_write_block:
> 
>        1. PIO write of param + extra (10 bytes) or even padded to 12 or 16 bytes
>        2. inline write (TPC_P0) of MS_CMD_BLOCK_WRITE + wait for int
>        3. read of INT register via STATUS
>        3. DMA write of MS_TPC_WRITE_LONG_DATA
>        4. DMA write of MS_TPC_WRITE_LONG_DATA
>            ---------timeout-----------
>  
>    * In fact first DMA write succedes, but next one fails, and so do all following writes
> 
>    * The problem persits till reboot, and shows up even if PIO isn't used again.
>    Other way to "fix" it, is to put device in D3 and back to D0
> 
>    * Serial/parallel mode don't affect anything.
> 
>    After bug reproduction:
> 
>     * DMA writes stop working completely, therefore mspro_blk looses writes as well
> 
>     * PIO still works just fine. Its possible just to load the driver without dma support, and it works correctly.
> 
>     * DMA reads work just fine.
> 
> #5: Auto_Get_INT feature just doesn't work.
>    Datasheet says that intreg is placed to TPC_P0, but that doesn't happen....
>    card status register is 0.
> 


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