Red Hat Bugzilla – Bug 146405
Load PNP stuff during boot
Last modified: 2007-11-30 17:10:59 EST
Since the new policy (with FC3) seems to be that all required modules
should be loaded at startup and not as needed (which I suppose is a
problem with udev), then it would be nice if all required modules are
actually loaded =)
What is missing is the PNP stuff. The id:s can be extracted from
/sys/bus/pnp/devices/*/id and converted into a string that associates
with a module.
Since a lot of hardware still only can be found using PNP (ACPI PNP
primarly on laptops with lots of LPC connected devices), this is a
greatly missed function.
Got a brief example of such a driver?
The problem in my case is my own driver :)
It is a SD/MMC card reader connected to the LPC bus. Currently there
exists only two ways to detect this chip:
1. Scan for the chip by issuing commands to ports it should be located
on and see if you get expected results.
2. Trigger on the PNP info in the ACPI DSDT.
So solution 2 is the one that "just works". The first requires that
the user has some idea about what hardware he has (which rarely is
specified) and knows what driver to use.
The driver in question is 'wbsd' and is included in 2.6.10 and
forward. PNP support isn't added to the main line yet, but will be as
soon as I'm confident that all the bugs are out.
This is only one example. From what I can tell, the parallell port
needs a similar solution and probably also serial ports. Basically
anything connected to the LPC bus.
Hm... those sorts of PNP ids aren't exported by modules anywhere, so
there's no way to know what to load. Unless I'm missing something.
Actually they are. The device here has id WEC0517. This gets generated
by the kernel build system to an alias pnp:dWEC0517* which can be
On your system you can do a 'modinfo parport_pc' and observe the PNP
aliases at the two last entries.
That *should* already get picked up, then.
Hm. The kernel wouldn't have happend to have changed what fields the
devices in /sys/devices/pnpX/XX.X export, would it?
It contains the same information, i.e. a file 'id' with the PNP id.
Should this be picked up by kmodule then or by some other part of the
OK, the code is currently set up for ISA PNP. Which has different
fields. I suppose I need to find a box that has both.
Could you give some pointers to which pieces of code are of interest here. That
way I could look deeper into it myself. Currently I haven't got a clue how the
magic works. :)
is the code in question.
Problem solved. ACPIPNP does not have the card abstraction that ISAPNP has. So
it would seem that devices get placed (in ACPIPNP) where cards would be places
I.e. /sys/devices/pnp0/* in ACPIPNP is equivalent to /sys/devices/pnp0/*/* in
This means that the name and card_id fields can be empty in the kudzu device. I
hope all software can handle this.
Created attachment 114223 [details]
This patch makes the probe function first check if there is an 'id' file in the
device root. If so then that id is used to create a kudzu device. Otherwise
normal ISAPNP probing continues.
This should be backwards compatible, but I don't have an ISAPNP machine to test
it on. It makes kmodule find my parallell port and SD card reader so it solves
Unfortunately, I don't have my isapnp test box any more either. :/
What's the output of 'kudzu -p -b isapnp' with this patch for you?
Created attachment 114224 [details]
kudzu -p -b isapnp
With an unpatched kudzu there is no output. The attached file contains the
output of the patched kudzu.
Ugh, 'compat' is a multi-line string there for one device? That's bound to break
Is that really something new? Or is ISAPNP restricted to one compatible id?
Anyway, it's here now so it needs to be handled.
Just keeping the first row is probably not a good approach since it will lose
data. compat probably needs to be changed into an array. Since kudzu is
statically linked, not dynamically, this shouldn't cause that much breakage. Any
applications dependent on old structures will be found during the next recompile.
Created attachment 114261 [details]
patch that fixes multi-line compat
Here's an updated patch that should handle the multi-line compat - does it work
for you on your box still? (I had to hack the kernel driver to get a device
with multiple compat entries. :) )
Works fine. The compat field is now a comma-separated list:
The synaptic touchpad is in a lot of laptops so it shouldn't be that difficult
to find a machine with this "feature" :)
Heh, just apparently not thinkpads.
The paranoid person in me thinks this should probably be left for post-FC4; will
Just not too much after. I try to keep in sync with rawhide so it would be nice
if it shows up there as soon as possible. :)
Added in CVS, will be in 0.1.117-1.
How about a rebuild of initscripts so that this change actually has an effect? ;)
Heh, thanks for the reminder. Will get to it in the next week or so.
This is broken again. Since kmodule seems to be retired in favor of udev I guess
it's a udev bug now.
Yeah, popping over there. Is this stuff exporting modalias files? If not, this
gets bumped to the kernel.
Yup. I can find it in modules.isapnp:
parport_pc 0xffff 0xffff 0x00000000 0xd041 0x0004
parport_pc 0xffff 0xffff 0x00000000 0xd041 0x0104
wbsd 0xffff 0xffff 0x00000000 0xa35c 0x1705
wbsd 0xffff 0xffff 0x00000000 0xa35c 0x1805
(wbsd is the one I really want loaded, it's for my card reader).
That may not be the same thing ... does /sys/bus/pnp/devices/<whatever> have a
Not sure what you're referring to. The modules are present in modules.alias at
least. And the mapping algorithm was discussed in previous comments in this bug.
udev, at boot, looks for uevent files in sysfs, and uses those to retrigger
device add events. If these events have a 'modalias', they should cause the
modules to get loaded. Unless we don't have a rule for PNP addition of
devices.... which we don't.
Harald, perhaps we just need a generic:
ACTION=="add", SUBSYSTEM=="*", MODALIAS=="*", RUN+="/sbin/modprobe $modalias"
to catch all subsystems?
Pierre, if you add that udev rule, does it start working?
Afraid not. To debug it I added the following:
ACTION=="add", SUBSYSTEM=="*", MODALIAS=="*", RUN+="/usr/bin/logger $modalias"
But when I echoed 'add' to the relevant uevent file, nothing happened. So there
might be a problem with the uevent triggering in the pnp layer.
> does /sys/bus/pnp/devices/<whatever> have a modalias file?
$ find /sys/bus/pnp/devices/ -name modalias
[drzeus@poseidon]$ find /sys/bus/pnp/devices/ -name modalias
[drzeus@poseidon]$ find /sys/bus/ -name modalias
But 'find /sys/ -name modalias' finds some entries. None for PNP though.
This is likely going to need quite a bit of work on the pnp layer, which should
really happen upstream (email@example.com) by those familiar with it
(and with the hardware to test).
That route doesn't seem to be the correct one (according to Kay Sievers at
least). Search LKML for "[PATCH] [PNP] 'modalias' sysfs export" if you want to
see the entire thread.
His final suggestion was to add this to the udev rules:
SUBSYSTEM=="pnp", RUN+="/bin/sh -c 'while read id; do /sbin/modprobe
pnp:d$$id; done < /sys$devpath/id'"
Reopening and moving to udev.
Any comment on Kay's suggestion?
IIRC, we tried that in <some other bug that I forget the name of> and it didn't
work for those cases.
So, in the short term, that suggestion would work for things like serial ports
and parallel ports. It won't work for soundcards, though.
That's still better than today where it doesn't work for anything.
What was the applied solution and in which version of which package?
ACTION=="add", SUBSYSTEM=="*", MODALIAS=="*", RUN+="modprobe $modalias"
SUBSYSTEM=="pnp", RUN+="/bin/sh -c 'while read id; do /sbin/modprobe pnp:d$$id;
done < /sys$devpath/id'"