linux-kernel - Re: [PATCH] My work on MemoryStick system

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] [day] [month] [year] [list]

Date:	Sun, 22 Aug 2010 23:35:26 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] My work on MemoryStick system

> > > 
> > > I just tested this series with Jmicron, and
> unfortunelly
> > > there are bugs.
> > > 
> > > * driver refuses to handle 26 byte TPC I use to
> read regs
> > > (sizeof(ms_registers). If I bump it to 32, it
> works.
> > 
> > It will work with any multiply of 4 (24 and 28 work as
> well). It's a known
> > "feature".
> Then I bump the size of ms_registers to 32 and leave this
> as is.
> OK?

I'd rather minimize the transfer size, than increase it.


> And I add a warning about this feature of some hardwares
> someplace.
> 
> 
> But what about MS_TPC_GET_INT. This asks for single byte.
> Hardware has to support it.

They've got a custom register for its value. GET_INT is implemented by
different hardware than READ/WRITE_REG

> 
> 
> 
> > 
> > > 
> > > * With this fix first few reads still fail.
> > > That means that card isn't detected always
> because boot
> > > blocks might not
> > > be read.
> > > Later card works fine.
> > > 
> > > * Also I found out that msproblk.c allocates
> memory for
> > > attributes IO
> > > using stock kmalloc, and hangs that to driver.
> > > However if driver doesn't support such address,
> it will
> > > fail.
> > 
> > Why would hardware do anything at all with attribute
> memory space?
> Read it?
> 
> You allocate the memory with kmalloc, create a sg with
> sg_init_one and
> pass that to driver.
> So therefore it can be from arbitrary address.

Yes, indeed.

> 
> I found further problems in jmicron driver:
> 
> 
> 1. Serial mode doesn't work well.
> I first read the boot block, and then enable parallel
> mode.
> I do so because boot block has a flag that tells if
> parallel mode is
> supported.
> It turns out that sector reads often don't finish,
> especially first and
> often second one which contain boot blocks.
> If I enable parallel mode right away problem goes away.

They have really weird dependency between clock setup and operation mode.
Try to use the clock setup values from the errata I've sent you.
The order of register initialization and reset timing seems to affect
the operation as well.

To summarize my opinion about it: if I had to design a card reader, I
won't even look at anything, but TI chips. :-)


> 
> 
> 2. the MS_TPC_WRITE_LONG_DATA fail, therefore I can't write
> anything to
> the stick.
> 
> As soon as my driver starts to write a block,  first
> MS_TPC_WRITE_LONG_DATA succeeds, but second one timeouts.
> (there is no MS_TPC_GET_INT in between, because of parallel
> mode).
> 
> Maybe I do something wrong in my ms_block.c, but I checked
> it many
> times, and it appears to be correct, and it works fine with
> r592.c
> 
> 
> 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/