lkml.org 
[lkml]   [2006]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
Date
On May 7, 2006, at 08:05:59, Krzysztof Halasa wrote:
> Kyle Moffett <mrmacman_g4@mac.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-07 21:11    [W:0.079 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site