linux-kernel - Re: Experimental driver for Ricoh Bay1Controller SD Card readers

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, 11 Feb 2007 21:22:37 +0100
From:	Sascha Sommer <saschasommer@...enet.de>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, rmk+mmc@....linux.org.uk,
	Elladan <elladan@...imo.com>,
	Samuel Thibault <samuel.thibault@...-lyon.org>,
	Pierre Ossman <drzeus-list@...eus.cx>
Subject: Re: Experimental driver for Ricoh Bay1Controller SD Card readers

Hi,

On Sunday 07 January 2007 10:56, Jiri Slaby wrote:
> Sascha Sommer wrote:
> > Hi,
> >
> > Attached is a very experimental driver for a Ricoh SD Card reader that
> > can be found in some notebooks like the Samsung P35.
> >
> > Whenever a sd card is inserted into one of these notebooks, a virtual
> > pcmcia card will show up:
> >
> > Socket 0:
> >   product info: "RICOH", "Bay1Controller", "", ""
> >   manfid: 0x0000, 0x0000
> >
> > In order to write this driver I hacked qemu to have access to the cardbus
> > bridge containing this card. I then logged the register accesses of the
> > windows xp driver and tryed to analyse them.
> >
> > As the meanings of most of the register are still unknown to me, I
> > consider this driver very experimental. It is possible that this driver
> > might destroy your data or your hardware. Use at your own risk!
> >
> > Other problems:
> > - I only implemented reading support
> > - I only tested with a 128 MB SD card, no idea what would be needed to
> > support other card types
> > - irqs are not supported
> > - dma is not supported
> > - it is very slow
> > - the registers can be found on the cardbus bridge and not on the virtual
> >   pcmcia card. The cardbus bridge is already claimed by yenta_socket.
> >   Therefore the driver currently uses pci_find_device to find the cardbus
>
> - pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put).
> - ioremap->pci_iomap
> - iobase should be __iomem.
> - codingstyle (char* buffer, for(loop, if(data){, ...)
>

Thanks for your feedback and testing.
I fixed the above problems and ran the code through Lindent.
Apart from that I did the following changes:
- implemented suspend/resume support (not tested very much)
- named the registers
- fixed a bug that caused a major slowdown when modprobed without debug=1
- added writting support (disabled by default, modprobe with write=1)
Before you enable writting please make sure that you did a proper backup of 
the data on the card. Do not use this driver to save important data.

I still consider this driver experimental, but without documentation this is 
probably not going to change anytime soon.
The question is now what I should do with the driver?
Is it worth to be included in the kernel? If yes where and against what 
kernelversion should I send the patch?


Thanks

Sascha


View attachment "Makefile" of type "text/x-makefile" (406 bytes)

View attachment "sdricoh_cs.c" of type "text/x-csrc" (15050 bytes)