linux-kernel - Re: Status of Ricoh Bay1Controller driver?

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]

Date:	Sun, 6 Jul 2008 09:09:30 +0200
From:	Sascha Sommer <saschasommer@...enet.de>
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	sdricohcs-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: Status of Ricoh Bay1Controller driver?

Hi,

On Sonntag, 6. Juli 2008, Pierre Ossman wrote:
> On Sat, 5 Jul 2008 21:11:49 +0200
>
> Sascha Sommer <saschasommer@...enet.de> wrote:
> > There is still some hack for ACMDs. I know you won't like that but I did
> > not get the SD_APP_SEND_SCR command to work without it.
> >
> > MMC_SEND_EXT_CSD does not work (also not with that ACMD hack) and prints
> > out something like:
>
> The SCR and EXT_CSD are both the only data transfers that are done in
> 1-bit mode in the respective init paths. Are you sure that hack you
> have for ACMDs is really for ACMDs and not for 1-bit transfers?
>
> (And you're right about me not liking that hack, but I can let that one
> slide as long as you agree it is important to get rid off ;))
>

Well I do not like the hacks either ;) However I'm out of ideas when it comes 
to these two commands. As far as I know the windows driver also does the |=64
for the SD_APP_OP_COND  and SD_APP_SET_BUS_WIDTH what are the only ACMDs. 
These aren't data read commands.

When I do not do the |= 64 the SD_APP_SEND_SCR command fails just like the 
MMC_SEND_EXT_CSD command.

#define MMC_SEND_EXT_CSD          8   /* adtc                    R1  */
#define MMC_SEND_CSD              9   /* ac   [31:16] RCA        R2  */
#define SD_APP_SEND_SCR          51   /* adtc                    R1  */

After the SD_APP_SEND_SCR command worked I tryed to fix the MMC_SEND_EXT_CSD 
command.
As you can see they look quite similar from the command description.
I tryed:
- different bit combination for what seem to be the command flags
- or the opcode with  |= 64, if this flag is for data transfers in one 1-bit
   mode this should have worked, shouldn't it?
- set the bus width to 4 bit before the read

Nothing worked ;( == The status register simply does not indicate that there 
is data available that can be read. It doesn't even change. Reading the data 
register nevertheless returns only zeros.

So to summarize this I agree that it is important to get rid off these 
hacks ;) but I don't have a better solution available at the moment ;(.

Regards

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