| xj | b04a402 | 2021-11-25 15:01:52 +0800 | [diff] [blame] | 1 | Accessing PCI device resources through sysfs | 
 | 2 | -------------------------------------------- | 
 | 3 |  | 
 | 4 | sysfs, usually mounted at /sys, provides access to PCI resources on platforms | 
 | 5 | that support it.  For example, a given bus might look like this: | 
 | 6 |  | 
 | 7 |      /sys/devices/pci0000:17 | 
 | 8 |      |-- 0000:17:00.0 | 
 | 9 |      |   |-- class | 
 | 10 |      |   |-- config | 
 | 11 |      |   |-- device | 
 | 12 |      |   |-- enable | 
 | 13 |      |   |-- irq | 
 | 14 |      |   |-- local_cpus | 
 | 15 |      |   |-- remove | 
 | 16 |      |   |-- resource | 
 | 17 |      |   |-- resource0 | 
 | 18 |      |   |-- resource1 | 
 | 19 |      |   |-- resource2 | 
 | 20 |      |   |-- revision | 
 | 21 |      |   |-- rom | 
 | 22 |      |   |-- subsystem_device | 
 | 23 |      |   |-- subsystem_vendor | 
 | 24 |      |   `-- vendor | 
 | 25 |      `-- ... | 
 | 26 |  | 
 | 27 | The topmost element describes the PCI domain and bus number.  In this case, | 
 | 28 | the domain number is 0000 and the bus number is 17 (both values are in hex). | 
 | 29 | This bus contains a single function device in slot 0.  The domain and bus | 
 | 30 | numbers are reproduced for convenience.  Under the device directory are several | 
 | 31 | files, each with their own function. | 
 | 32 |  | 
 | 33 |        file		   function | 
 | 34 |        ----		   -------- | 
 | 35 |        class		   PCI class (ascii, ro) | 
 | 36 |        config		   PCI config space (binary, rw) | 
 | 37 |        device		   PCI device (ascii, ro) | 
 | 38 |        enable	           Whether the device is enabled (ascii, rw) | 
 | 39 |        irq		   IRQ number (ascii, ro) | 
 | 40 |        local_cpus	   nearby CPU mask (cpumask, ro) | 
 | 41 |        remove		   remove device from kernel's list (ascii, wo) | 
 | 42 |        resource		   PCI resource host addresses (ascii, ro) | 
 | 43 |        resource0..N	   PCI resource N, if present (binary, mmap, rw[1]) | 
 | 44 |        resource0_wc..N_wc  PCI WC map resource N, if prefetchable (binary, mmap) | 
 | 45 |        revision		   PCI revision (ascii, ro) | 
 | 46 |        rom		   PCI ROM resource, if present (binary, ro) | 
 | 47 |        subsystem_device	   PCI subsystem device (ascii, ro) | 
 | 48 |        subsystem_vendor	   PCI subsystem vendor (ascii, ro) | 
 | 49 |        vendor		   PCI vendor (ascii, ro) | 
 | 50 |  | 
 | 51 |   ro - read only file | 
 | 52 |   rw - file is readable and writable | 
 | 53 |   wo - write only file | 
 | 54 |   mmap - file is mmapable | 
 | 55 |   ascii - file contains ascii text | 
 | 56 |   binary - file contains binary data | 
 | 57 |   cpumask - file contains a cpumask type | 
 | 58 |  | 
 | 59 | [1] rw for RESOURCE_IO (I/O port) regions only | 
 | 60 |  | 
 | 61 | The read only files are informational, writes to them will be ignored, with | 
 | 62 | the exception of the 'rom' file.  Writable files can be used to perform | 
 | 63 | actions on the device (e.g. changing config space, detaching a device). | 
 | 64 | mmapable files are available via an mmap of the file at offset 0 and can be | 
 | 65 | used to do actual device programming from userspace.  Note that some platforms | 
 | 66 | don't support mmapping of certain resources, so be sure to check the return | 
 | 67 | value from any attempted mmap.  The most notable of these are I/O port | 
 | 68 | resources, which also provide read/write access. | 
 | 69 |  | 
 | 70 | The 'enable' file provides a counter that indicates how many times the device  | 
 | 71 | has been enabled.  If the 'enable' file currently returns '4', and a '1' is | 
 | 72 | echoed into it, it will then return '5'.  Echoing a '0' into it will decrease | 
 | 73 | the count.  Even when it returns to 0, though, some of the initialisation | 
 | 74 | may not be reversed.   | 
 | 75 |  | 
 | 76 | The 'rom' file is special in that it provides read-only access to the device's | 
 | 77 | ROM file, if available.  It's disabled by default, however, so applications | 
 | 78 | should write the string "1" to the file to enable it before attempting a read | 
 | 79 | call, and disable it following the access by writing "0" to the file.  Note | 
 | 80 | that the device must be enabled for a rom read to return data successfully. | 
 | 81 | In the event a driver is not bound to the device, it can be enabled using the | 
 | 82 | 'enable' file, documented above. | 
 | 83 |  | 
 | 84 | The 'remove' file is used to remove the PCI device, by writing a non-zero | 
 | 85 | integer to the file.  This does not involve any kind of hot-plug functionality, | 
 | 86 | e.g. powering off the device.  The device is removed from the kernel's list of | 
 | 87 | PCI devices, the sysfs directory for it is removed, and the device will be | 
 | 88 | removed from any drivers attached to it. Removal of PCI root buses is | 
 | 89 | disallowed. | 
 | 90 |  | 
 | 91 | Accessing legacy resources through sysfs | 
 | 92 | ---------------------------------------- | 
 | 93 |  | 
 | 94 | Legacy I/O port and ISA memory resources are also provided in sysfs if the | 
 | 95 | underlying platform supports them.  They're located in the PCI class hierarchy, | 
 | 96 | e.g. | 
 | 97 |  | 
 | 98 | 	/sys/class/pci_bus/0000:17/ | 
 | 99 | 	|-- bridge -> ../../../devices/pci0000:17 | 
 | 100 | 	|-- cpuaffinity | 
 | 101 | 	|-- legacy_io | 
 | 102 | 	`-- legacy_mem | 
 | 103 |  | 
 | 104 | The legacy_io file is a read/write file that can be used by applications to | 
 | 105 | do legacy port I/O.  The application should open the file, seek to the desired | 
 | 106 | port (e.g. 0x3e8) and do a read or a write of 1, 2 or 4 bytes.  The legacy_mem | 
 | 107 | file should be mmapped with an offset corresponding to the memory offset | 
 | 108 | desired, e.g. 0xa0000 for the VGA frame buffer.  The application can then | 
 | 109 | simply dereference the returned pointer (after checking for errors of course) | 
 | 110 | to access legacy memory space. | 
 | 111 |  | 
 | 112 | Supporting PCI access on new platforms | 
 | 113 | -------------------------------------- | 
 | 114 |  | 
 | 115 | In order to support PCI resource mapping as described above, Linux platform | 
 | 116 | code should ideally define ARCH_GENERIC_PCI_MMAP_RESOURCE and use the generic | 
 | 117 | implementation of that functionality. To support the historical interface of | 
 | 118 | mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP. | 
 | 119 |  | 
 | 120 | Alternatively, platforms which set HAVE_PCI_MMAP may provide their own | 
 | 121 | implementation of pci_mmap_page_range() instead of defining | 
 | 122 | ARCH_GENERIC_PCI_MMAP_RESOURCE. | 
 | 123 |  | 
 | 124 | Platforms which support write-combining maps of PCI resources must define | 
 | 125 | arch_can_pci_mmap_wc() which shall evaluate to non-zero at runtime when | 
 | 126 | write-combining is permitted. Platforms which support maps of I/O resources | 
 | 127 | define arch_can_pci_mmap_io() similarly. | 
 | 128 |  | 
 | 129 | Legacy resources are protected by the HAVE_PCI_LEGACY define.  Platforms | 
 | 130 | wishing to support legacy functionality should define it and provide | 
 | 131 | pci_legacy_read, pci_legacy_write and pci_mmap_legacy_page_range functions. |