PCMCIA product id strings -> hashes generation at compilation
time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Dominik Brodowski
linux at dominikbrodowski.net
Tue Mar 8 18:16:36 EST 2005
> Dominik Brodowski <linux at dominikbrodowski.net> wrote:
> >
> > Most pcmcia devices are matched to drivers using "product ID strings"
> > embedded in the devices' Card Information Structures, as "manufactor ID /
> > card ID" matches are much less reliable. Unfortunately, these strings cannot
> > be passed to userspace for easy userspace-based loading of appropriate
> > modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes
> > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> >
> > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
>
> What is the difficulty in passing these strings via /sbin/hotplug arguments?
The difficulty is that extracting and evaluating them breaks the wonderful
bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
strings may contain spaces and other "strange" characters. The latter may be
worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
clean because of this MODNAME implementation:
#!/bin/sh
cd /etc/hotplug
. ./hotplug.functions
if [ "$ACTION" = "" ]; then
mesg Bad PCMCIA agent invocation, no action
exit 1
fi
case $ACTION in
add)
modprobe $MODNAME
... work around some exotic buggy PCMCIA hardware ...
...
and I would very much like to avoid breaking the line "modprobe $MODNAME".
On Tue, Mar 08, 2005 at 02:54:57PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 8 Mar 2005, Dominik Brodowski wrote:
> >
> > Unfortunately, these strings cannot
> > be passed to userspace for easy userspace-based loading of appropriate
> > modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes
> > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> >
> > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
>
> Hmm.. I'm with Andrew on this one - I'd much rather really pass them to
> user space as strings. We already pass a number of strings as environment
> variables.
>
> In fact, what's wrong with DEVPATH? Which we already expose as the
> NAME=xxx environment variable. So if the kboject associated with a device
> has has this string associated with its name (which it should)
drivers/base/core.c::device_add()
kobject_set_name(&dev->kobj, "%s", dev->bus_id);
and the bus_id isn't the device's name for common buses.
Nontheless, the strings _are_ exported at DEVPATH/prod_id[1-4], but for the
reasons mentioned above I'd prefer not to use them.
On Tue, Mar 08, 2005 at 12:34:26PM -0800, Andrew Morton wrote:
> > ...
> > To make the life easier for device driver authors,
> > - a big warning is put into dmesg if a pcmcia driver is inserted
> > into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID()
> > is incorrect,
>
> As long as the kernel shouts loudly at the driver developer at
> development-time, and that shouting mentions a bit of documentation in
> Documentation/somewhere, I expect we'll be OK.
Andrew, please apply this patch on top of 2.6.11-mm2, if you and Linus still
agree:
Add some information useful for PCMCIA device driver authors to
Documentation/pcmcia/, and reference it in dmesg in case of hash mismatches.
Also add a reference to pcmciautils to Documentation/Changes. With recent
changes, you don't need to concern yourself with pcmcia-cs even if you have
PCMCIA hardware, so the example above the list needed to be adapted as well.
Signed-off-by: Dominik Brodowski <linux at dominikbrodowksi.net>
Index: 2.6.11+/Documentation/Changes
===================================================================
--- 2.6.11+.orig/Documentation/Changes 2005-03-08 23:23:30.000000000 +0100
+++ 2.6.11+/Documentation/Changes 2005-03-08 23:23:33.000000000 +0100
@@ -44,9 +44,9 @@
Again, keep in mind that this list assumes you are already
functionally running a Linux 2.4 kernel. Also, not all tools are
-necessary on all systems; obviously, if you don't have any PCMCIA (PC
-Card) hardware, for example, you probably needn't concern yourself
-with pcmcia-cs.
+necessary on all systems; obviously, if you don't have any ISDN
+hardware, for example, you probably needn't concern yourself with
+isdn4k-utils.
o Gnu C 2.95.3 # gcc --version
o Gnu make 3.79.1 # make --version
@@ -57,6 +57,7 @@
o jfsutils 1.1.3 # fsck.jfs -V
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
o xfsprogs 2.6.0 # xfs_db -V
+o pcmciautils 001
o pcmcia-cs 3.1.21 # cardmgr -V
o quota-tools 3.09 # quota -V
o PPP 2.4.0 # pppd --version
@@ -186,13 +187,20 @@
work correctly with this version of the XFS kernel code (2.6.0 or
later is recommended, due to some significant improvements).
+PCMCIAutils
+-----------
+
+PCMCIAutils replaces pcmcia-cs (see below). It properly sets up
+PCMCIA sockets at system startup and loads the appropriate modules
+for 16-bit PCMCIA devices if the kernel is modularized and the hotplug
+subsystem is used.
Pcmcia-cs
---------
PCMCIA (PC Card) support is now partially implemented in the main
-kernel source. Pay attention when you recompile your kernel ;-).
-Also, be sure to upgrade to the latest pcmcia-cs release.
+kernel source. The "pcmciautils" package (see above) replaces pcmcia-cs
+for newest kernels.
Quota-tools
-----------
@@ -349,9 +357,13 @@
--------
o <ftp://oss.sgi.com/projects/xfs/download/>
+Pcmciautils
+-----------
+o <ftp://ftp.kernel.org/pub/linux/utils/kernel/pcmcia/>
+
Pcmcia-cs
---------
-o <ftp://pcmcia-cs.sourceforge.net/pub/pcmcia-cs/pcmcia-cs-3.1.21.tar.gz>
+o <http://pcmcia-cs.sourceforge.net/>
Quota-tools
----------
Index: 2.6.11+/Documentation/pcmcia/devicetable.txt
===================================================================
--- 2.6.11+.orig/Documentation/pcmcia/devicetable.txt 2005-03-08 22:41:21.540138608 +0100
+++ 2.6.11+/Documentation/pcmcia/devicetable.txt 2005-03-08 23:57:46.000000000 +0100
@@ -0,0 +1,64 @@
+Matching of PCMCIA devices to drivers is done using one or more of the
+following criteria:
+
+- manufactor ID
+- card ID
+- product ID strings _and_ hashes of these strings
+- function ID
+- device function (actual and pseudo)
+
+You should use the helpers in include/pcmcia/device_id.h for generating the
+struct pcmcia_device_id[] entries which match devices to drivers.
+
+If you want to match product ID strings, you also need to pass the crc32
+hashes of the string to the macro, e.g. if you want to match the product ID
+string 1, you need to use
+
+PCMCIA_DEVICE_PROD_ID1("some_string", 0x(hash_of_some_string)),
+
+If the hash is incorrect, the kernel will inform you about this in "dmesg"
+upon module initialization, and tell you of the correct hash.
+
+You can determine the hash of the product ID strings by running
+"pcmcia-modalias %n.%m" [%n being replaced with the socket number and %m being
+replaced with the device function] from pcmciautils. It generates a string
+in the following form:
+pcmcia:m0149cC1ABf06pfn00fn00pa725B842DpbF1EFEE84pc0877B627pd00000000
+
+The hex value after "pa" is the hash of product ID string 1, after "pb" for
+string 2 and so on.
+
+Alternatively, you can use this small tool to determine the crc32 hash.
+simply pass the string you want to evaluate as argument to this program,
+e.g.
+$ ./crc32hash "Dual Speed"
+
+-------------------------------------------------------------------------
+/* crc32hash.c - derived from linux/lib/crc32.c, GNU GPL v2 */
+#include <string.h>
+#include <stdio.h>
+#include <ctype.h>
+#include <stdlib.h>
+
+unsigned int crc32(unsigned char const *p, unsigned int len)
+{
+ int i;
+ unsigned int crc = 0;
+ while (len--)
+ crc ^= *p++;
+ for (i = 0; i < 8; i++)
+ crc = (crc >> 1) ^ ((crc & 1) ? 0xedb88320 : 0);
+ }
+ return crc;
+}
+
+int main(int argc, char **argv) {
+ unsigned int result;
+ if (argc != 2) {
+ printf("no string passed as argument\n");
+ return -1;
+ }
+ result = crc32(argv[1], strlen(argv[1]));
+ printf("0x%x\n", result);
+ return 0;
+}
Index: 2.6.11+/Documentation/pcmcia/driver-changes.txt
===================================================================
--- 2.6.11+.orig/Documentation/pcmcia/driver-changes.txt 2005-03-08 22:41:21.540138608 +0100
+++ 2.6.11+/Documentation/pcmcia/driver-changes.txt 2005-03-09 00:01:07.000000000 +0100
@@ -0,0 +1,51 @@
+This file details changes in 2.6 which affect PCMCIA card driver authors:
+
+* in-kernel device<->driver matching
+ PCMCIA devices and their correct drivers can now be matched in
+ kernelspace. See 'devicetable.txt' for details.
+
+* Device model integration (as of 2.6.11)
+ A struct pcmcia_device is registered with the device model core,
+ and can be used (e.g. for SET_NETDEV_DEV) by using
+ handle_to_dev(client_handle_t * handle).
+
+* Convert internal I/O port addresses to unsigned long (as of 2.6.11)
+ ioaddr_t should be replaced by kio_addr_t in PCMCIA card drivers.
+
+* irq_mask and irq_list parameters (as of 2.6.11)
+ The irq_mask and irq_list parameters should no longer be used in
+ PCMCIA card drivers. Instead, it is the job of the PCMCIA core to
+ determine which IRQ should be used. Therefore, link->irq.IRQInfo2
+ is ignored.
+
+* client->PendingEvents is gone (as of 2.6.11)
+ client->PendingEvents is no longer available.
+
+* client->Attributes are gone (as of 2.6.11)
+ client->Attributes is unused, therefore it is removed from all
+ PCMCIA card drivers
+
+* core functions no longer available (as of 2.6.11)
+ The following functions have been removed from the kernel source
+ because they are unused by all in-kernel drivers, and no external
+ driver was reported to rely on them:
+ pcmcia_get_first_region()
+ pcmcia_get_next_region()
+ pcmcia_modify_window()
+ pcmcia_set_event_mask()
+ pcmcia_get_first_window()
+ pcmcia_get_next_window()
+
+* device list iteration upon module removal (as of 2.6.10)
+ It is no longer necessary to iterate on the driver's internal
+ client list and call the ->detach() function upon module removal.
+
+* Resource management. (as of 2.6.8)
+ Although the PCMCIA subsystem will allocate resources for cards,
+ it no longer marks these resources busy. This means that driver
+ authors are now responsible for claiming your resources as per
+ other drivers in Linux. You should use request_region() to mark
+ your IO regions in-use, and request_mem_region() to mark your
+ memory regions in-use. The name argument should be a pointer to
+ your driver name. Eg, for pcnet_cs, name should point to the
+ string "pcnet_cs".
Index: 2.6.11+/drivers/pcmcia/ds.c
===================================================================
--- 2.6.11+.orig/drivers/pcmcia/ds.c 2005-03-08 23:23:30.000000000 +0100
+++ 2.6.11+/drivers/pcmcia/ds.c 2005-03-08 23:59:01.000000000 +0100
@@ -262,8 +262,6 @@
}
EXPORT_SYMBOL(cs_error);
-#ifdef CONFIG_PCMCIA_DEBUG
-
static void pcmcia_check_driver(struct pcmcia_driver *p_drv)
{
@@ -284,6 +282,9 @@
"product string \"%s\": is 0x%x, should "
"be 0x%x\n", p_drv->drv.name, did->prod_id[i],
did->prod_id_hash[i], hash);
+ printk(KERN_DEBUG "pcmcia: see "
+ "Documentation/pcmcia/devicetable.txt for "
+ "details\n");
}
did++;
}
@@ -291,12 +292,6 @@
return;
}
-#else
-static inline void pcmcia_check_driver(struct pcmcia_driver *p_drv) {
- return;
-}
-#endif
-
#ifdef CONFIG_PCMCIA_LOAD_CIS
More information about the linux-pcmcia
mailing list