Hi,
On Mon, Nov 20, 2006 at 09:53:49AM +0000, Russell King wrote:
> On Sun, Nov 19, 2006 at 11:38:51AM -0500, Dominik Brodowski wrote:
> >
> > From: Matt Reimer <mattjreimer@xxxxxxxxx>
> > Date: Thu, 26 Oct 2006 15:56:00 -0700
> > Subject: [PATCH] pcmcia: Add an id to ide-cs.c
> >
> > Add an ID entry for:
> >
> > product info: "TRANSCEND", "TS1GCF80", "", ""
> > manfid: 0x000a, 0x0000
> > function: 4 (fixed disk)
>
> Erm, silly question: isn't this supposed to be matched by the following:
>
> static struct pcmcia_device_id ide_ids[] = {
> PCMCIA_DEVICE_FUNC_ID(4),
>
> or are we going to be ignoring the function ID and only matching using
> the manfid and product info strings?
As the matching by func_id is fuzzy and gives false positives, this is a
multiple-step process:
a) the kernel checks all built-in and previously loaded modules for
prod_id and manf_id matches
b) userspace (udev/hotplug + modprobe) loads appropriate modules (including
those which are only matched by func_id
c) during the module initialization (e.g. modprobe hasn't returned yet) the
kernel checks the modules based on prod_id and manf_id matches
d) after all these modprobe calls return, userspace writes "1" into
/sys/$devpath/allow_func_id_match. Then, the kernel re-checks all
built-in and previously loaded modules for func_id "fuzzy" matches.
It is self-evident that steps b)-d) only work once userspace is ready. As
PCMCIA drivers should be able to work even before that, manf_id and prod_id
table entries do make sense even if func_id matching works.
Thanks,
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
