Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On May 6, 2006, at 19:16:25, Krzysztof Halasa wrote:
"Jon Smirl" <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux