Out of curiousity, what happens if, after loading the card, you do:

for file in `find /sys -name allow_func_id_match` ; do 
    echo "1" > $file
done

?

Please also post the output of /sys/bus/pcmcia/devices/0.0/modalias for the CF
cards which are not handled automagically yet.

Results from:
> for file in `find /sys -name allow_func_id_match` ; do 
>     echo "1" > $file
> done

Jul 29 14:24:32 white kernel: hda: LEXAR ATA_FLASH, CFA DISK drive
Jul 29 14:24:33 white kernel: ide0 at 0x100-0x107,0x10e on irq 3
Jul 29 14:24:33 white kernel: hda: max request size: 128KiB
Jul 29 14:24:33 white kernel: hda: 32128 sectors (16 MB) w/1KiB Cache, CHS=502/2/32
Jul 29 14:24:33 white kernel: hda: cache flushes not supported
Jul 29 14:24:33 white kernel:  hda: hda1
Jul 29 14:24:33 white kernel: ide-cs: hda: Vcc = 3.3, Vpp = 0.0
Jul 29 14:24:33 white kernel:  hda: hda1
Jul 29 14:24:34 white last message repeated 2 times
Jul 29 14:24:34 white fstab-sync[7507]: added mount point /media/FSCK0000DIA for
/dev/hda1
Jul 29 14:24:34 white kernel:  hda: hda1


It mounted!

From 'cat /sys/bus/pcmcia/devices/0.0/modalias' for each failed card:

Lexar 16MB
pcmcia:m4E01c0200f04fn00pfn00pa144506E2pb7F641C27pc3488C81Apd00000000

Lexar 160MB
pcmcia:m4E01c0200f04fn00pfn00pa144506E2pb7F641C27pc438FF88Cpd00000000

Lexar 512MB
pcmcia:m4E01c0200f04fn00pfn00paAC17E994pbE82DAB83pcC9B37BA4pd00000000

Simple 192MB
pcmcia:m0007c0000f04fn00pfn00paBF2DF18Dpb8CB57A0Epc00000000pd00000000

Created attachment 117300 [details]
kernel-patch

This patch (on top of 2.6.13-rc4-git1) adds the proper device table entries for
these cards. However, the function ID matching method should have picked them
up automatically, with no manual interaction (such as the shell script Bill
Nottingham posted) necessary. Any idea what went wrong in
/etc/hotplug/pcmcia.agent ?

> Any idea what went wrong in /etc/hotplug/pcmcia.agent ?

File does not exist.

We're just using straight udev rules:

ACTION=="add", SUBSYSTEM=="pcmcia", MODALIAS=="*", \
        RUN+="/sbin/modprobe $modalias"

Not to ask a stupid question, but why does that sysfs attribute even exist? If
it defaults to handling all devices of that function, it really shouldn't
require extra steps to claim devices it matches.

We need to distinguish two types of priority in matching the devices to drivers.
If we have a MANFID/CARDID or PRODID match, we can safely use the driver.
However, FUNCID matches are much more fuzzy: it can generate "false positives".
Therefore, these need to be delayed until all other, possibly more appropriate
modules have had a chance to bind themselves to the driver.

What's to prevent the pcmcia.agent continuing and setting that field while still
waiting for some other driver (loaded with a MODALIAS that matches multiple
modules) to decide whether or not to match it?

well, "modprobe $MODALIAS" only returns if all drivers are loaded and fully
initialized. This includes running the drivers' _init() function, which calls
pcmcia_register_driver(), which might eventually call the probe callback. All in
the same process/thread, so we're safe in this regard.

Same problem for my Dane-Elec CF cards.

# pccardctl ident
Socket 0:
  product info: "TOSHIBA THNCF256MMA ", "", "", ""
  manfid: 0x0098, 0x0000
  function: 4 (fixed disk)
Socket 1:
  no product info available

nothing in syslog or /etc/fstab

# echo 1 > /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0f.0/0.0/allow_func_id_match
Jul 30 17:30:23 brian kernel: Probing IDE interface ide2...
Jul 30 17:30:23 brian kernel: hde: TOSHIBA THNCF256MMA, CFA DISK drive
Jul 30 17:30:24 brian kernel: ide2 at 0xd000-0xd007,0xd00e on irq 3
Jul 30 17:30:24 brian kernel: hde: max request size: 128KiB
Jul 30 17:30:24 brian kernel: hde: 500736 sectors (256 MB) w/2KiB Cache,
CHS=978/16/32
Jul 30 17:30:24 brian kernel: hde: cache flushes not supported
Jul 30 17:30:24 brian kernel:  hde: hde1
Jul 30 17:30:24 brian kernel: ide-cs: hde: Vcc = 3.3, Vpp = 0.0
Jul 30 17:30:24 brian kernel:  hde: hde1
Jul 30 17:30:24 brian last message repeated 2 times
Jul 30 17:30:25 brian fstab-sync[4006]: added mount point /media/TOSHIBA256M1
for /dev/hde1

# cat /sys/bus/pcmcia/devices/0.0/modalias
pcmcia:m0098c0000f04fn00pfn00paF378DB98pb00000000pc00000000pd00000000
 
My scandisk CF card works fine.

PS: is there a way to define the mount point manually instead of the generated
/media/TOSHIBA256M1 or /media/idedisk3 (for the scandisk card)?

-Marcel

Should I open a new bugzilla entry against pcmciautils-007-1 so that
/etc/hotplug/pcmcia.agent gets included in the RPM?

I've added the ID for Dane-Elec CF (comment #11) to the patch I'll submit for
kernel 2.6.14-rc1. However allow_func_id_match still needs to be handled
correctly, else we'll see many more failures similar to the ones observed here.

Created attachment 117347 [details]
load modules in the order of how accurate the match is

Dominik: so, if the delay & echo from userspace is there to ensure that ide-cs
would be the last driver to bind to the device, would you accept something like
the following?

The attached patch for module-init-tools orders modules by how specific the
match is against the passed in id - basically, the match with the least number
of wildcards is loaded first, and so on.

This would ensure that something like ide_cs/serial_cs/parport_cs is loaded
last, and binds last, without having another trip to userspace for a magic
flag.

Is this an acceptable solution to have the sysfs flag removed? :)

(As an aside, is this really a problem where there are other, better, matches
for ide-cs? Or is that primarily for serial_cs/parport_cs?)

This isn't a valid option -- one PROD_ID match is much better than one FUNC_ID
match. Why don't you do something like
ACTION=="add", SUBSYSTEM=="pcmcia", MODALIAS=="*", \
        RUN+="/sbin/modprobe $modalias && \
     echo 42 > /sys/bus/pcmcia/devices/$SOMETHING/allow_func_id_match"
instead?

Well, RUN+= is done with exec(), so you can't *quite* do it like that. But it's
doable, yes.

It's mainly the interface which I find cumbersome/hackish. What sorts of cards
are these where matching on function is bad? Ignoring the fact that the kernel
system doesn't support exporting this, is it something that's better handled by
blacklisting those cards in ide_cs/etc rather than whitelisting the
vendor/device of all the cards that *are* handled by ide_cs?

Added a rule in udev-063-5.