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

[Krzysztof Halasa <khc@pm.waw.pl>]

Kyle Moffett <mrmacman_g4@mac.com> writes:

> "device class and/or IDs ... can contain garbage".  That seems to
> violate PCI spec to me.

Well, maybe not exactly garbage but just no useful IDs.

> 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). 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.

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).

> 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?

That isn't possible in this case.

The EEPROM has to be written somehow anyway.

>  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".
-- 
Krzysztof Halasa
-
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/