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 - 15:08:11 EST
On May 7, 2006, at 08:05:59, Krzysztof Halasa wrote:
Kyle Moffett <mrmacman_g4@xxxxxxx> writes:
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.
Writing EEPROM is not a problem and can be done safely from user
space (mmap /dev/mem).
This is *exactly* what we don't want to do! The whole point of this
thread is to prevent the need to use /dev/mem and /dev/kmem for
anything except debugging.
Doing it in the kernel seems like an overkill, especially if you do
the operation once in few years it's much easier to just download a
(statically linked?) binary than messing with the kernel.
Ewww, I certainly wouldn't trust a binary statically-linked binary
program that mmaps /dev/mem or /dev/kmem, and I certainly bet that
90% of the people on this list would feel likewise. We'd much prefer
a program which does this:
#! /bin/sh
cp firmware.bin /lib/firmware/some_firmware_file.bin
echo -n eeprom_load_driver >/sys/device/$PCI_ID/bind
echo -n 1 >/sys/device/$PCI_ID/unbind
Simple, obviously correct, and uses a nice reuseable driver too!
It doesn't even interfere with the "main" driver and can be done
while the device is operating (given that previous EEPROM made
sense, otherwise the driver would not load).
No! That would be even worse! You're then having userspace poke at
the driver while a kernel driver is loaded, which is *exactly* what X
is getting into trouble for doing. If you want to add firmware
update capability, add it to the preexisting primary driver.
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.
Right. I.e., "enable" interface with, possibly, locking mechanism,
instead of some per-class "driver".
No, not an "enable" interface. In this case the kernel should do
basically all of the poking at PCI resources for you. If you
_really_ want to do that kind of update in userspace, write a stub
driver which just enables the device on bind, disables it on unbind,
and mmap and write to the sysfs "rom" file.
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/