linux-kernel - Re: [PATCH 23/29] memstick: jmb38x_ms: use DMA for all TPCs with len greater that 8 by default

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: <1288060186.4024.186.camel@maxim-laptop>
Date:	Tue, 26 Oct 2010 04:29:46 +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 23/29] memstick: jmb38x_ms: use DMA for all TPCs with
 len greater that 8 by default

On Mon, 2010-10-25 at 09:12 -0700, Alex Dubov wrote:
> --- On Fri, 22/10/10, Maxim Levitsky <maximlevitsky@...il.com> wrote:
> 
> > From: Maxim Levitsky <maximlevitsky@...il.com>
> > Subject: [PATCH 23/29] memstick: jmb38x_ms: use DMA for all TPCs with len greater that 8 by default
> > To: "Alex Dubov" <oakad@...oo.com>
> > Cc: "Andrew Morton" <akpm@...ux-foundation.org>, "LKML" <linux-kernel@...r.kernel.org>, "Maxim Levitsky" <maximlevitsky@...il.com>
> > Received: Friday, 22 October, 2010, 4:53 PM
> > This is to workaround a wierd
> > hardware bug:
> > 
> > If PIO write is used, and then after it DMA write is used,
> > DMA
> > engine stops doing writes.
> > That condition even persists after device reset.
> > 
> > To be maxumum safe, we do dma to a scratch page
> > and memcpy from/to it.
> > 
> > Besides this change should just improve performance.
> > 
> > Signed-off-by: Maxim Levitsky <maximlevitsky@...il.com>
> > ---
> 
> I have not noticed this one before, and for all I know the driver was
> tested at Jmicron.
> Can you explain the issue a bit more?
Because you didn't test MS standard, or always wrote OOB and param by
seperate TPCs.

You really don't read my mail.

<quote>
***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

   * TPC_P0, TPC_P1 not aligned transfters work just fine despite a
statement in the datasheet
   (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....
</quote>

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