On May 7, 2006, at 08:05:59, Krzysztof Halasa wrote:
Kyle Moffett <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: Martin Mares <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: Greg KH <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: "Jon Smirl" <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: Greg KH <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: "Jon Smirl" <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: "Dave Airlie" <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: "Jon Smirl" <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: Krzysztof Halasa <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: "Jon Smirl" <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: Krzysztof Halasa <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: "Jon Smirl" <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: Krzysztof Halasa <[email protected]>
- 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 <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- From: Krzysztof Halasa <[email protected]>
- Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- Prev by Date: [PATCH] Bluetooth: fix potential NULL ptr deref in dtl1_cs.c::dtl1_hci_send_frame()
- Next by Date: Re: [PATCH] Bluetooth: fix potential NULL ptr deref in dtl1_cs.c::dtl1_hci_send_frame()
- Previous by thread: Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- Next by thread: Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
- Index(es):
 |