| 1 | Parameters for modprobe and insmod |
|---|
| 2 | ================================== |
|---|
| 3 | |
|---|
| 4 | PRELIMINARY WARNING: |
|---|
| 5 | This documentation file is outdated and needs to be entirely reviewed |
|---|
| 6 | and updated. Until then, don't blindly trust what you read here. |
|---|
| 7 | |
|---|
| 8 | ================================== |
|---|
| 9 | SUMMARY |
|---|
| 10 | |
|---|
| 11 | [modprobe,insmod] module {parameter...} |
|---|
| 12 | Parameters: |
|---|
| 13 | force=bus,address{,bus,address} |
|---|
| 14 | force_addr=address{,address} |
|---|
| 15 | force_[chipname]=bus,address{,bus,address} |
|---|
| 16 | force_subclients=bus,caddr,saddr,saddr |
|---|
| 17 | ignore=bus,address{,bus,address} |
|---|
| 18 | ignore_range=bus,start,end{,bus,start,end} |
|---|
| 19 | probe=bus,address{,bus,address} |
|---|
| 20 | probe_range=bus,start,end{,bus,start,end} |
|---|
| 21 | init=[0,1] (default 1) |
|---|
| 22 | |
|---|
| 23 | All arguments are in decimal unless prefixed by "0x". |
|---|
| 24 | No spaces are allowed. |
|---|
| 25 | |
|---|
| 26 | ================================== |
|---|
| 27 | OVERVIEW |
|---|
| 28 | |
|---|
| 29 | All chip drivers have a few modprobe module parameters in common. |
|---|
| 30 | (Insmod can also be used, but we recommend modprobe so that |
|---|
| 31 | other required modules are automatically loaded.) These |
|---|
| 32 | parameters can be used when a module is inserted, to give some additional |
|---|
| 33 | information about how it should function. In this case, they tell where |
|---|
| 34 | the module should look for what chips. Usually, you don't need them, and |
|---|
| 35 | if you do, you are often told by sensors-detect which ones you need. |
|---|
| 36 | |
|---|
| 37 | If a module doesn't load with no parameters, you may need to |
|---|
| 38 | add parameters. Check 'dmesg' for clues to what went wrong. |
|---|
| 39 | |
|---|
| 40 | |
|---|
| 41 | BUS NUMBERING |
|---|
| 42 | ------------- |
|---|
| 43 | I2C/SMBus adapters are numbered in the order they are inserted. If you want |
|---|
| 44 | to know what number an adapter has, use the following command: |
|---|
| 45 | |
|---|
| 46 | (for kernel 2.6.32 and newer) |
|---|
| 47 | grep . /sys/bus/i2c/devices/i2c-*/name |
|---|
| 48 | |
|---|
| 49 | (for kernel 2.6.31 and older) |
|---|
| 50 | grep . /sys/class/i2c-adapter/i2c-*/name |
|---|
| 51 | |
|---|
| 52 | Alternatively, if you have installed i2c-tools, you can do: |
|---|
| 53 | |
|---|
| 54 | modprobe i2c-dev |
|---|
| 55 | i2cdetect -l |
|---|
| 56 | |
|---|
| 57 | If you want 'any I2C bus', use '-1'. |
|---|
| 58 | |
|---|
| 59 | |
|---|
| 60 | ADDRESS NUMBERING |
|---|
| 61 | ----------------- |
|---|
| 62 | Each adapter has a number of addresses on I2C/SMBus adapters and/or the |
|---|
| 63 | ISA bus that are always scanned if no modprobe parameters are given. The |
|---|
| 64 | parameters below override those addresses that are scanned by default. |
|---|
| 65 | |
|---|
| 66 | All modprobe parameters described below take lists of positive integers |
|---|
| 67 | (unsigned, in the range of 0 to 65535) as their arguments. Integers |
|---|
| 68 | are separated by comma's, and may be given as ordinary decimal numbers, |
|---|
| 69 | as octal numbers (by starting them with a `0') or as hexadecimal numbers |
|---|
| 70 | (by starting them with a `0x'). More information can be found by |
|---|
| 71 | entering `man modprobe' or `man insmod'. |
|---|
| 72 | So to summarize: |
|---|
| 73 | 0x00 - 0x7f Valid I2C Addresses |
|---|
| 74 | 0x0000 - 0xffff Valid ISA Bus Addresses |
|---|
| 75 | |
|---|
| 76 | |
|---|
| 77 | ================================== |
|---|
| 78 | PARAMETER DETAILS |
|---|
| 79 | |
|---|
| 80 | `force', `force_*', `ignore' and `probe' parameters take pairs of numbers. |
|---|
| 81 | Each first (odd) number is a bus number, each second (even) number is |
|---|
| 82 | an (I2C or ISA) address. |
|---|
| 83 | |
|---|
| 84 | `ignore_range' and `probe_range' parameters take triples of numbers. |
|---|
| 85 | Each first number is a bus number, each second number is the start address |
|---|
| 86 | of a range, and each third number is the end address of a range. Ranges |
|---|
| 87 | are always inclusive. |
|---|
| 88 | |
|---|
| 89 | `probe' and `probe_range' parameters tell the module to scan additional |
|---|
| 90 | addresses for a specific bus. These are treated just as the ordinary |
|---|
| 91 | addresses scanned. This is useful for some chips that can be anywhere; |
|---|
| 92 | to keep loading time (and false detections) down, only the most common |
|---|
| 93 | addresses are scanned by default. |
|---|
| 94 | |
|---|
| 95 | `ignore' and `ignore_range' parameters tell the module not to scan |
|---|
| 96 | specific addresses. They overrule the default addresses and any |
|---|
| 97 | addresses specified by `probe' and `probe_range' statements. |
|---|
| 98 | |
|---|
| 99 | The `force' parameter tells the module a supported chip is found at |
|---|
| 100 | a specific address. It overrules all previously mentioned parameters. |
|---|
| 101 | Sometimes, a chip can be in a specific internal state that makes |
|---|
| 102 | detection impossible. If you specify it with the `force' parameter, |
|---|
| 103 | it is first put into a recognizable state. Also, some detection routines |
|---|
| 104 | are skipped. If the module supports several chips, it will still try |
|---|
| 105 | to determine what chip is found on that address. If it can't determine |
|---|
| 106 | this, the address will still not be used. |
|---|
| 107 | |
|---|
| 108 | There is a `force_*' parameter for each type of chip supported by a |
|---|
| 109 | module. This is the strongest statement possible - it says that a |
|---|
| 110 | specific type of chip is found on a specific address, and the module |
|---|
| 111 | will skip all detection and recognition routines. This can lead to |
|---|
| 112 | very strange results... |
|---|
| 113 | |
|---|
| 114 | `force_addr' is a parameter used for PCI sensor adapters. |
|---|
| 115 | It is used to program the base address of the sensor registers. |
|---|
| 116 | This is required if the BIOS does not initialize the base address. |
|---|
| 117 | |
|---|
| 118 | `force_subclients' is used to force the i2c addresses for subclients of |
|---|
| 119 | a certain chip. Typical usage is `force_subclients=0,0x2d,0x4a,0x4b' |
|---|
| 120 | to force the subclients of chip 0x2d on bus 0 to i2c addresses |
|---|
| 121 | 0x4a and 0x4b. |
|---|
| 122 | This parameter is currently supported only by the w83781d driver |
|---|
| 123 | and is useful for certain Tyan boards. |
|---|
| 124 | |
|---|
| 125 | `init' is used to tell a driver to bypass initializing a chip. |
|---|
| 126 | This may be necessary if the BIOS has initialized the chip a certain way |
|---|
| 127 | and the driver should not overwrite that initialization. |
|---|
| 128 | It is also useful if normal initialization crashes the system. |
|---|
| 129 | The default is 1, so the only useful value is `init=0'. |
|---|
| 130 | This parameter is currently supported only by the w83781d driver. |
|---|
| 131 | |
|---|
| 132 | ================================== |
|---|
| 133 | EXAMPLE |
|---|
| 134 | |
|---|
| 135 | # ISA address 0x390 contains a LM79 |
|---|
| 136 | # Scan all I2C addresses (from 0 to 0x7f) for all I2C adapters |
|---|
| 137 | # But skip address 0x2d on adapter 0, and address 0x20 on adapter 1 |
|---|
| 138 | |
|---|
| 139 | modprobe lm78 force_lm79=9191,0x390 ignore=0,0x2d,1,0x20 probe_range=-1,0,0x7f |
|---|