Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Kyle Moffett
Date: Sun May 07 2006 - 02:00:36 EST
On May 6, 2006, at 19:16:25, Krzysztof Halasa wrote:
"Jon Smirl" <jonsmirl@xxxxxxxxx> writes:
The card in question _has_ a driver. I, for example, just need a
way to write EEPROM data to it (vendor/device ID etc). The card
has to be selected by PCI bus and slot (device) number, not by
device class and/or IDs, because it can contain garbage and/or
some generic IDs with generic device class.
Hardware like you describe violates the PCI spec
What exactly does it violate?
"device class and/or IDs ... can contain garbage". That seems to
violate PCI spec to me.
I would probably handle this by writing an unbound device driver
that exposes a sysfs file for bus:slot. When you write the
bus:slot to the file it would then bind to the appropriate
hardware and enable it. The newly bound driver would support the
driver firmware loader interface as a means of getting your data in.
What is also needed is that end users perform this task from time
to time. They generally don't want to have to compile the kernel :-)
You know, even now it can be done (entirely in userspace), and only
enabling the device seems a bit dangerous.
Jon Smirl gave a great description of exactly how to write such a
"driver". I seem to recall that we already have the ability to
trigger manual PCI binding by bus:slot number; in combination with an
appropriate "write EEPROM with firmware file" driver that has no
default list of PCI devices; you could easily manually trigger a bind
of the device. On the other hand I would personally never put such a
device in my system, what if the garbage device IDs happened to match
a device with poorly-written PCI IDE drivers that panic when they
bind to a device which does not match their expectations? In any
case what you really need for all those cases is a simplistic stub
driver that provides some sort of in-kernel mutual exclusion.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/