Before you get your hopes up, this development model is not one that will get

your code merged upstream. You should really try to work with Alex, not side

step him. Drivers are rarely complex enough to warrant, or even have room for, a

rewrite. And judging from your code it looks more like reorganising the code

that's already there.
In short, this "rewrite" won't fly. Report the issues you have with the current

driver and work with the existing maintainer to get them fixed.
Rgds

--

     -- Pierre Ossman
  Linux kernel, MMC maintainer        http://www.kernel.org

  PulseAudio, core developer          http://pulseaudio.org

  rdesktop, core developer          http://www.rdesktop.org

-

It is a sad truth. Instead of raising real issues that may remain in the driver, I was presented

with "non-proof" that bus-adapter-device architecture I'm using is somehow bad and the driver

should be turned into a monolithic blob, using config variables to disable unneeded functionality.

Considering, that udev handles automatic loading of the drivers just fine (so it's not an end user

issue at any rate), I don't see any justification for the change.
__________________________________________________

Do You Yahoo!?

Tired of spam?  Yahoo! Mail has the best spam protection around

http://mail.yahoo.com

-

I may be doing something the wrong way. I absolutely don't intend to

start flames in this list.
Alex, your driver is great. You have done enormous amount of work,

reverse engineering proprietary drivers. Since the territory you work on

is unchartered, you can choose any design model, you see appropriate.
However, since we are working in an open community, everyone can give

his opinion on this issue. The commenter must definitely back his words

with real arguments. The patch at the top of this thread is such an

argument. You may or may not care about it, at will.
I have submitted my version only after I have failed to find a stable

version of your driver for the current kernel. If there is one, just

post link to the patch. If not, let's make one.

-

As I already said, I'm not aware of any issues with version 0.8 of the driver. If you have any

problems with it, I'll be glad to fix them.
The version in question was recently committed into the -mm tree. Otherwise, it's available from

the project's website for a couple of months now:
http://developer.berlios.de/project/showfiles.php?group_id=5510
__________________________________________________

Do You Yahoo!?

Tired of spam?  Yahoo! Mail has the best spam protection around

http://mail.yahoo.com

-

It seems a bit out-of-date. Here is the output:
build-i386-sony-tx770p$ make

scripts/kconfig/conf -s arch/i386/Kconfig

  CHK     include/linux/version.h

  CHK     include/linux/utsrelease.h

  CHK     include/linux/compile.h

  CC [M]  drivers/misc/tifm_core.o

  CC [M]  drivers/misc/tifm_7xx1.o

  CC [M]  drivers/mmc/tifm_sd.o

drivers/mmc/tifm_sd.c: In function ‘tifm_sd_probe’:

drivers/mmc/tifm_sd.c:987: error: ‘struct mmc_host’ has no member named

‘max_sectors’

make[2]: *** [drivers/mmc/tifm_sd.o] Error 1

make[1]: *** [drivers/mmc] Error 2

make: *** [drivers] Error 2
This is with v2.6.21 and your tarball unpacked like this:

linux/tifm.h -> include/linux/tifm.h

tifm_sd.c -> drivers/mmc/tifm_sd.c

tifm_7xx1.c -> drivers/misc/tifm_7xx1.c

tifm_core.c -> drivers/misc/tifm_core.c
I will look in mm and write back.

-

It clearly says there that the driver is for 2.6.20. The changes needed for 2.6.21 are actually

very small (couple of fields in the mmc layer were renamed).
In general, it is impossible to maintain out-of-tree driver in sync with kernel tree - too many

changes are committed into it. The -mm version obviously fits its tree.
__________________________________________________

Do You Yahoo!?

Tired of spam?  Yahoo! Mail has the best spam protection around

http://mail.yahoo.com

-

I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.

After [tifm_sd] is loaded. My smoke test script at
http://bugzilla.kernel.org/attachment.cgi?id=11240&action=view
reliably hangs suspend.
I didn't even see a failure for 'modprove -r tifm', which

doesn't exist in this build.
I will try to bisect git-mmc.patch to locate the source of

trouble. And I will compile my version to check it against

-mm tree.

-

I really wish you would stop removing me from cc...
Suspend is broken in -mm for all controllers. There is a bit of a race between

the resume and remove functions that causes things to deadlock. I have a fix,

but I'm working on pushing a lot of stuff to Linus right now so it might take a

few days before things hit the repos.
Rgds
--

     -- Pierre Ossman
  Linux kernel, MMC maintainer        http://www.kernel.org

  PulseAudio, core developer          http://pulseaudio.org

  rdesktop, core developer          http://www.rdesktop.org

-

I prepared a tarball with 2.6.21 compatible driver (tifm-0.8e on berlios). I don't see any

problems on stock 2.6.21.1. You may want to test it on your machine.
__________________________________________________

Do You Yahoo!?

Tired of spam?  Yahoo! Mail has the best spam protection around

http://mail.yahoo.com

-

This is "good enough" to withdraw my patch. I have filed it to

http://bugzilla.kernel.org/attachment.cgi?id=11312&action=view
in bug 8052

http://bugzilla.kernel.org/show_bug.cgi?id=8052
which seems to be resolved by the patch.
 > I don't see any problems on stock 2.6.21.1.
Well, this version seem to ignore cards which are present at

load.
I have this output:

~$ check once

Loading module tifm_sd ...

Checking for a card at /dev/mmcblk0p1 ...

failed.
for this script:

http://bugzilla.kernel.org/attachment.cgi?id=11317&action=view
and you can can see this bug for more details:

http://bugzilla.kernel.org/show_bug.cgi?id=8393
-

What is "modprobe tifm"? What modules have you loaded when it hangs?
__________________________________________________

Do You Yahoo!?

Tired of spam?  Yahoo! Mail has the best spam protection around

http://mail.yahoo.com

-

> What is "modprobe tifm"?
I believe is the relevant part:

~$ lsmod | grep "mmc\|tifm"

tifm_sd                11272  0

mmc_core               25812  1 tifm_sd

tifm_7xx1               6848  0

tifm_core               9876  2 tifm_sd,tifm_7xx1
Since there are [tifm_*] in lsmod; modprobe tifm is no run.
Can you successfully run this test with -mm tree? I that case

the fault may be hardware related.

-

I have uploaded an updated version to bugzilla:

http://bugzilla.kernel.org/attachment.cgi?id=11308&action=view

-