[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080114173835.5fe907db@hyperion.delvare>
Date: Mon, 14 Jan 2008 17:38:35 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
Cc: Jon Smirl <jonsmirl@...il.com>, linuxppc-dev@...abs.org,
i2c@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [i2c] [PATCH] update module-init-tools to support the i2c
subsystem
Hi Geert,
On Mon, 14 Jan 2008 11:57:52 +0100 (CET), Geert Uytterhoeven wrote:
> On Sun, 13 Jan 2008, Jon Smirl wrote:
> > I don't know exactly what those modules tables are used for. I just
> > copied what the other subsystems do. Maybe they are used when you make
> > an initrd to know which drivers to copy into the image.
>
> Module-init-tools needs those table to create module aliases in the *.ko
> files from the MODULE_DEVICE_TABLE(), so udev can load the modules based
> on the device IDs when the devices appear in sysfs.
I thought that the module aliases were generated by
scripts/mod/modpost? As a matter of fact, I did not apply Jon's patch
to module-init-tools, and "modinfo" shows me module aliases properly
for i2c drivers that call MODULE_DEVICE_TABLE():
$ /sbin/modinfo lm90
filename: /lib/modules/2.6.24-rc7-git4/kernel/drivers/hwmon/lm90.ko
author: Jean Delvare <khali@...ux-fr.org>
description: LM90/ADM1032 driver
license: GPL
vermagic: 2.6.24-rc7-git4 mod_unload
depends: hwmon
alias: i2c:Nlm90*
alias: i2c:Nadm1032*
alias: i2c:Nlm99*
alias: i2c:Nlm86*
alias: i2c:Nmax6657*
alias: i2c:Nadt7461*
alias: i2c:Nmax6680*
$
"modprobe i2c:Nadm1032" loads the lm90 driver as expected.
> That's the generic part. How this applies to i2c devices on platforms
> without Open Firmware device trees is another question. I guess that's
> where Jean gets confused (i2c_device_id got _removed_ last year,
> because it didn't make sense (at the time?)).
The way it was implemented back then did not make sense. As it was not
clear whether we would implement something different or nothing at all,
I decided to plain remove it. Now that it seems that we want to
implement it differently, I'm looking into it again.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists