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: <749211.91566.qm@web37603.mail.mud.yahoo.com>
Date:	Tue, 10 Aug 2010 01:12:47 -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.

> Received: Monday, 9 August, 2010, 8:30 AM
> I have another question.
> 
> Looking at ms_block.c, I see that it sometimes changes
> register window.
> This doesn't look good.
> I see it does put the register window back, but still its a
> bit obscure.

It looks very good, in fact, it is the Sony specified way to operate
the media. MS Pro works quite the same, it just needs fewer operations
to actually access data.

> 
> I added tracking of current register window, so every time
> I send
> MS_TPC_SET_RW_REG_ADRS I note the ranges.
> And read/write functions now always attempt to send
> MS_TPC_SET_RW_REG_ADRS. If the window is same as was 
> set last time, TPC
> is skipped.

Sure it is. The media will remember the window set.
Media has all its registers in a sort of flat file. SET_RW_REG_ADDR
selects the subset of the registers that will receive the data delivered
within TPC. This subset is remembered until power off or until changed.

> 
> However, I am thinking, that maybe I should always write
> both param and
> extra register? I just write 0xFF to extra register and
> thats all.

You should write into a param register when you want to alter the command
parameters. You cannot do so during auto incrementing block access, for
example.

But, if you're using the auto incrementing write, you will have to write
extra register for every page transferred.

That's where changing RW_REG_ADDR comes handy.

> Windows driver does that partially. It writes 0xFF to
> managmemt and
> 0xF8 to overwrite flag (why???)

It's a factory default.
Try to read it from some empty block. :-)
(My theory is that missing bits contain invisible ECC data).

> I don't
> think that matters.
> It also always sends the MS_TPC_SET_RW_REG_ADRS, which I
> don't like.
> 

This only reduces the performance slightly. SET_RW_REG_ADDR does not
influence the media's state machine as far as I can tell, unless you try
to push it during the data transfer cycle (whereupon you will end up
having a literal value of the tpc in the media data buffer).

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