This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 146405 - Load PNP stuff during boot
Load PNP stuff during boot
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-27 17:03 EST by Pierre Ossman
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-29 09:42:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
ACPIPNP patch (3.92 KB, patch)
2005-05-10 16:05 EDT, Pierre Ossman
no flags Details | Diff
kudzu -p -b isapnp (1.38 KB, text/plain)
2005-05-10 16:35 EDT, Pierre Ossman
no flags Details
patch that fixes multi-line compat (4.68 KB, patch)
2005-05-11 17:47 EDT, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Pierre Ossman 2005-01-27 17:03:10 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.
Comment 1 Bill Nottingham 2005-01-27 23:34:40 EST
Got a brief example of such a driver?
Comment 2 Pierre Ossman 2005-01-28 02:26:44 EST
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.
Comment 3 Bill Nottingham 2005-01-28 02:42:34 EST
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.
Comment 4 Pierre Ossman 2005-01-28 03:16:33 EST
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.
Comment 5 Bill Nottingham 2005-01-28 16:58:26 EST
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?
Comment 6 Pierre Ossman 2005-01-28 18:56:21 EST
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?
Comment 7 Bill Nottingham 2005-01-28 23:05:35 EST
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.
Comment 8 Pierre Ossman 2005-05-10 08:52:24 EDT
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. :)
Comment 9 Bill Nottingham 2005-05-10 12:29:43 EDT
kudzu/isapnp.c

is the code in question.
Comment 10 Pierre Ossman 2005-05-10 16:01:24 EDT
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.
Comment 11 Pierre Ossman 2005-05-10 16:05:10 EDT
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.
Comment 12 Bill Nottingham 2005-05-10 16:13:09 EDT
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?
Comment 13 Pierre Ossman 2005-05-10 16:35:37 EDT
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.
Comment 14 Bill Nottingham 2005-05-10 16:43:41 EDT
Ugh, 'compat' is a multi-line string there for one device? That's bound to break
something.
Comment 15 Pierre Ossman 2005-05-10 16:54:55 EDT
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.
Comment 16 Bill Nottingham 2005-05-11 17:47:40 EDT
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. :) )
Comment 17 Pierre Ossman 2005-05-11 17:59:38 EDT
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" :)
Comment 18 Bill Nottingham 2005-05-11 18:02:20 EDT
Heh, just apparently not thinkpads.

The paranoid person in me thinks this should probably be left for post-FC4; will
apply then.
Comment 19 Pierre Ossman 2005-05-11 18:08:46 EDT
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. :)
Comment 20 Bill Nottingham 2005-05-17 10:51:38 EDT
Added in CVS, will be in 0.1.117-1.
Comment 21 Bill Nottingham 2005-05-17 11:28:57 EDT
Erm, 1.1.117-1.
Comment 22 Pierre Ossman 2005-08-11 08:31:59 EDT
How about a rebuild of initscripts so that this change actually has an effect? ;)
Comment 23 Bill Nottingham 2005-08-19 02:15:29 EDT
Heh, thanks for the reminder. Will get to it in the next week or so.
Comment 24 Pierre Ossman 2006-01-07 14:17:54 EST
This is broken again. Since kmodule seems to be retired in favor of udev I guess
it's a udev bug now.
Comment 25 Bill Nottingham 2006-01-09 13:28:18 EST
Yeah, popping over there. Is this stuff exporting modalias files? If not, this
gets bumped to the kernel.
Comment 26 Pierre Ossman 2006-01-10 04:03:39 EST
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).
Comment 27 Bill Nottingham 2006-01-10 12:53:32 EST
That may not be the same thing ... does /sys/bus/pnp/devices/<whatever> have a
modalias file?
Comment 28 Pierre Ossman 2006-01-10 13:54:51 EST
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.
Comment 29 Bill Nottingham 2006-01-10 14:11:36 EST
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?
Comment 30 Pierre Ossman 2006-01-10 15:28:46 EST
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.
Comment 31 Harald Hoyer 2006-01-11 10:32:12 EST
> does /sys/bus/pnp/devices/<whatever> have a modalias file?

$ find /sys/bus/pnp/devices/  -name modalias
Comment 32 Pierre Ossman 2006-01-11 11:04:11 EST
~
[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.
Comment 33 Dave Jones 2006-02-27 02:47:39 EST
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).  
Comment 34 Pierre Ossman 2006-03-12 13:11:18 EST
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.
Comment 35 Pierre Ossman 2006-05-05 08:40:15 EDT
Ping!

Any comment on Kay's suggestion?
Comment 36 Bill Nottingham 2006-05-05 11:13:45 EDT
IIRC, we tried that in <some other bug that I forget the name of> and it didn't
work for those cases.
Comment 37 Bill Nottingham 2006-11-03 12:21:18 EST
So, in the short term, that suggestion would work for things like serial ports
and parallel ports. It won't work for soundcards, though.
Comment 38 Pierre Ossman 2006-11-03 13:55:56 EST
That's still better than today where it doesn't work for anything.
Comment 39 Pierre Ossman 2007-01-29 09:57:29 EST
What was the applied solution and in which version of which package?
Comment 40 Harald Hoyer 2007-01-29 10:11:01 EST
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

Note You need to log in before you can comment on or make changes to this bug.