lkml.org 
[lkml]   [2006]   [May]   [7]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromKyle Moffett <>
SubjectRe: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
DateSun, 7 May 2006 01:56:11 -0400
On May 6, 2006, at 19:16:25, Krzysztof Halasa wrote:
> "Jon Smirl" <jonsmirl@gmail.com> 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@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 05:59    [from the cache]
©2003-2008