0

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?

Armali
  • 18,255
  • 14
  • 57
  • 171
  • 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 Jul 15 '13 at 13:21
  • What architecture are you working with? Does it use device tree files? – Benjamin Leinweber Jul 15 '13 at 15:00
  • @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 Jul 16 '13 at 07:24
  • @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 Jul 16 '13 at 14:05
  • 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 Jul 17 '13 at 06:51

1 Answers1

0

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

Community
  • 1
  • 1
Armali
  • 18,255
  • 14
  • 57
  • 171