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 modprobe:d. 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 system?
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. :)
kudzu/isapnp.c 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 with ISAPNP. I.e. /sys/devices/pnp0/* in ACPIPNP is equivalent to /sys/devices/pnp0/*/* in ISAPNP. 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] ACPIPNP patch 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 my problem.
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 something.
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: class: UNSPEC bus: ISAPNP detached: 0 driver: unknown desc: "SYN0107" deviceId: SYN0107 compat: SYN0100,SYN0002,PNP0f13 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 apply then.
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.
Erm, 1.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 modalias file?
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]$ OTOH: ~ [drzeus@poseidon]$ find /sys/bus/ -name modalias ~ [drzeus@poseidon]$ 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 (linux-kernel@vger.kernel.org) 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.
Ping! 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" and SUBSYSTEM=="pnp", RUN+="/bin/sh -c 'while read id; do /sbin/modprobe pnp:d$$id; done < /sys$devpath/id'" since FC-6