0
votes

At present, I have a Linux 2.6 kernel module which accesses a certain device via pci_get_device() and pci_read_config_dword(). In future, the module shall be modified to also work a different machine which seems to have no PCI bus (/sys/bus/pci doesn't exist), but has the certain device at a fixed, known address. Now, I would like to have one module binary without parameters which works on both machines. To be able to load the module on the non-PCI machine, I think I must refrain from using pci_get_device() etc.; thus I have to get the needed config space info on the PCI machine in some other way. I could read it from /sys/bus/pci/devices/.../resource in my init_module(), but I gather it is considered bad practice to make kernel modules read files. Are there better ways to achieve my goal?

1
If you have a PCI device, you have a PCI bus. So either you're having a different problem (can't find bus, for example), or in the second system your device is not actually connected via PCI, but via some other local bus. As an aside, pci_get_device is not the standard way to write drivers for PCI devices. Have you read the PCI chapter of "Linux Device Drivers 3"? - Peter
What architecture are you working with? Does it use device tree files? - Benjamin Leinweber
@Peter: Well, I already assumed in my question that the second system has no PCI bus; indeed, the device must be connected via some other bus. The module is not an actual driver for a PCI device, but a pseudo driver that accesses the device memory among other memory regions; therefore, pci_register_driver() instead of pci_get_device() doesn't suit. @BenjaminLeinweber: The CPU in both systems is a PowerPC MPC5200. Yes, there are device-trees in both systems. - Armali
@Armali: if the device can be connected with two different busses, you'll need two different code paths to talk to it. To avoid parameters, just first check for a PCI device, then if it fails, try whatever probe will work for your other bus. Based on which one succeeds, set a variable in your device struct that indicates how to talk to it, and wrap this decision behind low-level accessor functions. - Peter
Of course, that's basically the way to go. But the core of my question is: Are there better ways to get the PCI address info than reading /sys/bus/pci/devices/.../resource? - Armali

1 Answers

0
votes

When functions like pci_get_device() cannot be used (because the module must work also with kernels that don't provide such functions), apparently there is no better way to get the PCI address info than reading /sys/bus/pci/devices/.../resource. I resorted to doing so, using filp_open(), vfs_read() and filp_close() on the basis of How to read/write files within a Linux kernel module?.