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: <950622.87676.qm@web37605.mail.mud.yahoo.com>
Date:	Tue, 10 Aug 2010 00:53:43 -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.

> About INT bits, I still don't
> understand them exactly.
> 
> First of all we have 4 meaningful bits.
> In parallel mode these are exposed on data lines, in serial
> mode only 
> MEMSTICK_INT_CED is.
> And I can always send MS_TPC_GET_INT or just read the
> registers.
> 
> #define MEMSTICK_INT_CMDNAK 0x01

This bit means command was not acknowledged by the media (media not ready).

> #define MEMSTICK_INT_BREQ   0x20

This bit means media is ready for long data transfer (either in or out).

> #define MEMSTICK_INT_ERR    0x40

This bit means that some error had occurred during command execution. 

> #define MEMSTICK_INT_CED    0x80

This bit marks a completion of the command, but it may switch value in
between, so it is not that reliable by itself.

> 
> 
> Now, I send a command to device, say MS_CMD_BLOCK_READ.
> What bits I need to poll until I can be sure that command
> is completed?

All of them.

> 
> Also the MEMSTICK_INT_BREQ tells that input is available in
> firmware
> buffer (to read using TPC_READ_LONG_DATA)?
> 

Not exactly. BREQ signal indicated that media's state machine is in the
mode to pump data in or out. You wait for it, than you do the data
transfer (it works the same with READ and WRITE).

> 
> 
> Is that true that MEMSTICK_INT_BREQ is a summary of fifo
> full/empty bits
> in status0?

This can not be relied upon. Sony states, that only BREQ bit must be used
in block transfer operations. BE/BF bits are probably of more use in
memstick IO cards (there exists such a beast).

> 
> And same about MEMSTICK_INT_ERR and status1.

status1 errors apply only to data errors (bit flips).
There are errors in command execution that do not result in bit flips,
rather data can not be delivered at all or command/parameters are invalid.


> 
> I try my best to create a driver that actually works,
> simple, and error
> free, even in unusual conditions.
> Thats why I am asking all these questions.
> 
> Thanks for help,
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ