Re: [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection
Hello, Am Tue, 29 Dec 2015 22:02:37 +0100 schrieb SF Markus Elfring <elfr...@users.sourceforge.net>: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:45:34 +0100 > > This issue was detected by using the Coccinelle software. > > Two pointer checks could be repeated by the sdricoh_init_mmc() > function during error handling even if the relevant properties can be > determined for the involved variables before by source code analysis. > > * This implementation detail could be improved by adjustments > for jump targets according to the Linux coding style convention. > > * Drop an unnecessary initialisation for the variable "mmc" then. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> > --- Acked-by: Sascha Sommer <saschasom...@freenet.de> Best regards Sascha
Re: [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection
Hello, Am Tue, 29 Dec 2015 22:02:37 +0100 schrieb SF Markus Elfring : > From: Markus Elfring > Date: Tue, 29 Dec 2015 21:45:34 +0100 > > This issue was detected by using the Coccinelle software. > > Two pointer checks could be repeated by the sdricoh_init_mmc() > function during error handling even if the relevant properties can be > determined for the involved variables before by source code analysis. > > * This implementation detail could be improved by adjustments > for jump targets according to the Linux coding style convention. > > * Drop an unnecessary initialisation for the variable "mmc" then. > > Signed-off-by: Markus Elfring > --- Acked-by: Sascha Sommer Best regards Sascha
Re: [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc()
Hello, Am Tue, 29 Dec 2015 22:00:35 +0100 schrieb SF Markus Elfring <elfr...@users.sourceforge.net>: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Tue, 29 Dec 2015 21:11:45 +0100 > > These variables will eventually be set to an appropriate value a bit > later. > * host > * iobase > * result > > Thus let us omit the explicit initialisation at the beginning. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Acked-by: Sascha Sommer <saschasom...@freenet.de> Best regards Sascha
Re: [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc()
Hello, Am Tue, 29 Dec 2015 22:00:35 +0100 schrieb SF Markus Elfring : > From: Markus Elfring > Date: Tue, 29 Dec 2015 21:11:45 +0100 > > These variables will eventually be set to an appropriate value a bit > later. > * host > * iobase > * result > > Thus let us omit the explicit initialisation at the beginning. > > Signed-off-by: Markus Elfring Acked-by: Sascha Sommer Best regards Sascha
Re: [PATCH 22/27] mmc: sdricoh_cs: Move away from using deprecated APIs
Hi,
Am Thu, 26 Sep 2013 16:54:47 +0200
schrieb Ulf Hansson :
> Suspend and resume of cards are being handled from the protocol layer
> and consequently the mmc_suspend|resume_host APIs are deprecated.
>
> This means we can simplify the suspend|resume callbacks by removing
> the use of the deprecated APIs.
>
> Cc: Sascha Sommer
> Signed-off-by: Ulf Hansson
> ---
> drivers/mmc/host/sdricoh_cs.c |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdricoh_cs.c
> b/drivers/mmc/host/sdricoh_cs.c index 50adbd1..b7e3057 100644
> --- a/drivers/mmc/host/sdricoh_cs.c
> +++ b/drivers/mmc/host/sdricoh_cs.c
> @@ -516,9 +516,7 @@ static void sdricoh_pcmcia_detach(struct
> pcmcia_device *link) #ifdef CONFIG_PM
> static int sdricoh_pcmcia_suspend(struct pcmcia_device *link)
> {
> - struct mmc_host *mmc = link->priv;
> dev_dbg(>dev, "suspend\n");
> - mmc_suspend_host(mmc);
> return 0;
> }
>
> @@ -527,7 +525,6 @@ static int sdricoh_pcmcia_resume(struct
> pcmcia_device *link) struct mmc_host *mmc = link->priv;
> dev_dbg(>dev, "resume\n");
> sdricoh_reset(mmc_priv(mmc));
> - mmc_resume_host(mmc);
> return 0;
> }
> #else
Acked-by: Sascha Sommer
Regards
Sascha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/27] mmc: sdricoh_cs: Move away from using deprecated APIs
Hi,
Am Thu, 26 Sep 2013 16:54:47 +0200
schrieb Ulf Hansson ulf.hans...@linaro.org:
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing
the use of the deprecated APIs.
Cc: Sascha Sommer saschasom...@freenet.de
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/sdricoh_cs.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/mmc/host/sdricoh_cs.c
b/drivers/mmc/host/sdricoh_cs.c index 50adbd1..b7e3057 100644
--- a/drivers/mmc/host/sdricoh_cs.c
+++ b/drivers/mmc/host/sdricoh_cs.c
@@ -516,9 +516,7 @@ static void sdricoh_pcmcia_detach(struct
pcmcia_device *link) #ifdef CONFIG_PM
static int sdricoh_pcmcia_suspend(struct pcmcia_device *link)
{
- struct mmc_host *mmc = link-priv;
dev_dbg(link-dev, suspend\n);
- mmc_suspend_host(mmc);
return 0;
}
@@ -527,7 +525,6 @@ static int sdricoh_pcmcia_resume(struct
pcmcia_device *link) struct mmc_host *mmc = link-priv;
dev_dbg(link-dev, resume\n);
sdricoh_reset(mmc_priv(mmc));
- mmc_resume_host(mmc);
return 0;
}
#else
Acked-by: Sascha Sommer saschasom...@freenet.de
Regards
Sascha
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, On Tuesday 13 February 2007 06:47, Pierre Ossman wrote: > Sascha Sommer wrote: > > 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? > > That's up to you. The most important thing for any part of the kernel is > that it must have a maintainer. So if you are ready to keep the driver > up to date and handle the support requests that show, then you should > really submit it. > > Patches should always be sent against the current version of the kernel > (i.e. git HEAD). Usually the latest packaged release will also do. > > (Note that I haven't had time to review your latest version of the driver) > Yes, I'm going to maintain it. There are still some bugs that need to be fixed first, though. I also got a mail from someone else how also did some reverseengineering work for this reader. I'm waiting for his feedback before I will submit a patch that can be included. Thanks. Sascha - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, On Tuesday 13 February 2007 06:47, Pierre Ossman wrote: Sascha Sommer wrote: 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? That's up to you. The most important thing for any part of the kernel is that it must have a maintainer. So if you are ready to keep the driver up to date and handle the support requests that show, then you should really submit it. Patches should always be sent against the current version of the kernel (i.e. git HEAD). Usually the latest packaged release will also do. (Note that I haven't had time to review your latest version of the driver) Yes, I'm going to maintain it. There are still some bugs that need to be fixed first, though. I also got a mail from someone else how also did some reverseengineering work for this reader. I'm waiting for his feedback before I will submit a patch that can be included. Thanks. Sascha - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 0x, 0x
> >
> > 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
KERNEL_VERSION = $(shell uname -r)
KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build
MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc
obj-m += sdricoh_cs.o
default:
$(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
install:
if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi
install -D -m 644 *.ko $(MDIR)
depmod -a
clean:
rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags
rm -rf .tmp_versions
/*
* sdricoh_cs.c - driver for Ricoh Secure Digital Card Readers that can be found
* on some Ricoh RL5c476 II cardbus bridge
*
* Copyright (C) 2006 - 2007 Sascha Sommer <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* FIXME:
* - what about irqs and dma?
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define DRIVER_NAME "sdricoh_cs"
#define DRIVER_VERSION "0.1"
static unsigned int debug = 0;
static unsigned int write = 0;
//#define DEBUG
/* debug macros */
#ifdef DEBUG
#define REGDBG(fmt, arg...) do {\
if (debug > 1) \
printk(KERN_INFO "sdricoh_cs: "fmt, \
##arg); } while (0)
#else
#define REGDBG(fmt, arg...)
#endif
#define DBG(fmt, arg...) do {\
if (debug > 0) \
printk(KERN_INFO "sdricoh_cs: "fmt, \
##arg); } while (0)
#define ERR(fmt, arg...) do {\
printk(KERN_INFO "sdricoh_cs: "fmt, \
##arg); } while (0)
/* i/o region */
#define SDRICOH_PCI_REGION 0
#define SDRICOH_PCI_REGION_SIZE 0x1000
/* registers */
#define R104_VERSION 0x104
#define R200_CMD 0x200
#define R204_
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: 0x, 0x
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
KERNEL_VERSION = $(shell uname -r)
KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build
MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc
obj-m += sdricoh_cs.o
default:
$(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
install:
if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi
install -D -m 644 *.ko $(MDIR)
depmod -a
clean:
rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags
rm -rf .tmp_versions
/*
* sdricoh_cs.c - driver for Ricoh Secure Digital Card Readers that can be found
* on some Ricoh RL5c476 II cardbus bridge
*
* Copyright (C) 2006 - 2007 Sascha Sommer [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* FIXME:
* - what about irqs and dma?
*/
#include linux/delay.h
#include linux/highmem.h
#include linux/pci.h
#include linux/ioport.h
#include pcmcia/cs_types.h
#include pcmcia/cs.h
#include pcmcia/cistpl.h
#include pcmcia/ciscode.h
#include pcmcia/ds.h
#include pcmcia/cisreg.h
#include asm/io.h
#include linux/mmc/host.h
#include linux/mmc/protocol.h
#define DRIVER_NAME sdricoh_cs
#define DRIVER_VERSION 0.1
static unsigned int debug = 0;
static unsigned int write = 0;
//#define DEBUG
/* debug macros */
#ifdef DEBUG
#define REGDBG(fmt, arg...) do {\
if (debug 1) \
printk(KERN_INFO sdricoh_cs: fmt, \
##arg); } while (0)
#else
#define REGDBG(fmt, arg...)
#endif
#define DBG(fmt, arg...) do {\
if (debug 0) \
printk(KERN_INFO sdricoh_cs: fmt, \
##arg); } while (0)
#define ERR(fmt, arg...) do {\
printk(KERN_INFO sdricoh_cs: fmt, \
##arg); } while (0)
/* i/o region */
#define SDRICOH_PCI_REGION 0
#define SDRICOH_PCI_REGION_SIZE 0x1000
/* registers */
#define R104_VERSION 0x104
#define R200_CMD 0x200
#define R204_CMD_ARG 0x204
#define R208_DATAIO 0x208
#define R20C_RESP0x20c
#define R21C_STATUS 0x21c
#define R2E0_INIT0x2e0
#define R2E4_STATUS_RESP 0x2e4
#define R2F0_RESET 0x2f0
#define R224_CLOCK
Experimental driver for Ricoh Bay1Controller SD Card readers
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: 0x, 0x 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 bridge containing the sd card reader registers. - it will probably crash when you remove the sd card without unmounting first - the ios stuff is not really understood - there are a bunch of extra MMC_APP_CMDs inside the driver - only tested with kernel 2.6.18 apart from all these problems reading an image from my sd card seems to have worked ;) If you are still brave enough to try it out make at least a backup of the data on your sd card. Feedback is highly appreciated. Regards Sascha KERNEL_VERSION = $(shell uname -r) KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc obj-m += sdricoh_cs.o default: $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules install: if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi install -D -m 644 *.ko $(MDIR) depmod -a clean: rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags rm -rf .tmp_versions sdricoh_cs.c.gz Description: GNU Zip compressed data
Experimental driver for Ricoh Bay1Controller SD Card readers
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: 0x, 0x 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 bridge containing the sd card reader registers. - it will probably crash when you remove the sd card without unmounting first - the ios stuff is not really understood - there are a bunch of extra MMC_APP_CMDs inside the driver - only tested with kernel 2.6.18 apart from all these problems reading an image from my sd card seems to have worked ;) If you are still brave enough to try it out make at least a backup of the data on your sd card. Feedback is highly appreciated. Regards Sascha KERNEL_VERSION = $(shell uname -r) KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc obj-m += sdricoh_cs.o default: $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules install: if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi install -D -m 644 *.ko $(MDIR) depmod -a clean: rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags rm -rf .tmp_versions sdricoh_cs.c.gz Description: GNU Zip compressed data
