diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/arm/Samsung-S3C24XX/Suspend.txt | 8 | ||||
-rw-r--r-- | Documentation/arm/memory.txt | 9 | ||||
-rw-r--r-- | Documentation/cputopology.txt | 6 | ||||
-rw-r--r-- | Documentation/devices.txt | 6 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 3 | ||||
-rw-r--r-- | Documentation/i2c/busses/i2c-nforce2 | 12 | ||||
-rw-r--r-- | Documentation/i2c/busses/i2c-piix4 | 2 | ||||
-rw-r--r-- | Documentation/i2c/instantiating-devices | 167 | ||||
-rw-r--r-- | Documentation/i2c/writing-clients | 19 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 13 | ||||
-rw-r--r-- | Documentation/scsi/osd.txt | 198 | ||||
-rw-r--r-- | Documentation/x86/boot.txt | 18 |
12 files changed, 435 insertions, 26 deletions
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt index 0dab6e32c130..a30fe510572b 100644 --- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt +++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt | |||
@@ -40,13 +40,13 @@ Resuming | |||
40 | Machine Support | 40 | Machine Support |
41 | --------------- | 41 | --------------- |
42 | 42 | ||
43 | The machine specific functions must call the s3c2410_pm_init() function | 43 | The machine specific functions must call the s3c_pm_init() function |
44 | to say that its bootloader is capable of resuming. This can be as | 44 | to say that its bootloader is capable of resuming. This can be as |
45 | simple as adding the following to the machine's definition: | 45 | simple as adding the following to the machine's definition: |
46 | 46 | ||
47 | INITMACHINE(s3c2410_pm_init) | 47 | INITMACHINE(s3c_pm_init) |
48 | 48 | ||
49 | A board can do its own setup before calling s3c2410_pm_init, if it | 49 | A board can do its own setup before calling s3c_pm_init, if it |
50 | needs to setup anything else for power management support. | 50 | needs to setup anything else for power management support. |
51 | 51 | ||
52 | There is currently no support for over-riding the default method of | 52 | There is currently no support for over-riding the default method of |
@@ -74,7 +74,7 @@ statuc void __init machine_init(void) | |||
74 | 74 | ||
75 | enable_irq_wake(IRQ_EINT0); | 75 | enable_irq_wake(IRQ_EINT0); |
76 | 76 | ||
77 | s3c2410_pm_init(); | 77 | s3c_pm_init(); |
78 | } | 78 | } |
79 | 79 | ||
80 | 80 | ||
diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index dc6045577a8b..43cb1004d35f 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt | |||
@@ -29,7 +29,14 @@ ffff0000 ffff0fff CPU vector page. | |||
29 | CPU supports vector relocation (control | 29 | CPU supports vector relocation (control |
30 | register V bit.) | 30 | register V bit.) |
31 | 31 | ||
32 | ffc00000 fffeffff DMA memory mapping region. Memory returned | 32 | fffe0000 fffeffff XScale cache flush area. This is used |
33 | in proc-xscale.S to flush the whole data | ||
34 | cache. Free for other usage on non-XScale. | ||
35 | |||
36 | fff00000 fffdffff Fixmap mapping region. Addresses provided | ||
37 | by fix_to_virt() will be located here. | ||
38 | |||
39 | ffc00000 ffefffff DMA memory mapping region. Memory returned | ||
33 | by the dma_alloc_xxx functions will be | 40 | by the dma_alloc_xxx functions will be |
34 | dynamically mapped here. | 41 | dynamically mapped here. |
35 | 42 | ||
diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 45932ec21cee..b41f3e58aefa 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt | |||
@@ -18,11 +18,11 @@ For an architecture to support this feature, it must define some of | |||
18 | these macros in include/asm-XXX/topology.h: | 18 | these macros in include/asm-XXX/topology.h: |
19 | #define topology_physical_package_id(cpu) | 19 | #define topology_physical_package_id(cpu) |
20 | #define topology_core_id(cpu) | 20 | #define topology_core_id(cpu) |
21 | #define topology_thread_siblings(cpu) | 21 | #define topology_thread_cpumask(cpu) |
22 | #define topology_core_siblings(cpu) | 22 | #define topology_core_cpumask(cpu) |
23 | 23 | ||
24 | The type of **_id is int. | 24 | The type of **_id is int. |
25 | The type of siblings is cpumask_t. | 25 | The type of siblings is (const) struct cpumask *. |
26 | 26 | ||
27 | To be consistent on all architectures, include/linux/topology.h | 27 | To be consistent on all architectures, include/linux/topology.h |
28 | provides default definitions for any of the above macros that are | 28 | provides default definitions for any of the above macros that are |
diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 2be08240ee80..62254d4510c6 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt | |||
@@ -3145,6 +3145,12 @@ Your cooperation is appreciated. | |||
3145 | 1 = /dev/blockrom1 Second ROM card's translation layer interface | 3145 | 1 = /dev/blockrom1 Second ROM card's translation layer interface |
3146 | ... | 3146 | ... |
3147 | 3147 | ||
3148 | 260 char OSD (Object-based-device) SCSI Device | ||
3149 | 0 = /dev/osd0 First OSD Device | ||
3150 | 1 = /dev/osd1 Second OSD Device | ||
3151 | ... | ||
3152 | 255 = /dev/osd255 256th OSD Device | ||
3153 | |||
3148 | **** ADDITIONAL /dev DIRECTORY ENTRIES | 3154 | **** ADDITIONAL /dev DIRECTORY ENTRIES |
3149 | 3155 | ||
3150 | This section details additional entries that should or may exist in | 3156 | This section details additional entries that should or may exist in |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 049a96247f58..1135996bec8b 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -340,7 +340,8 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl> | |||
340 | --------------------------- | 340 | --------------------------- |
341 | 341 | ||
342 | What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client() | 342 | What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client() |
343 | When: 2.6.29 (ideally) or 2.6.30 (more likely) | 343 | When: 2.6.30 |
344 | Check: i2c_attach_client i2c_detach_client | ||
344 | Why: Deprecated by the new (standard) device driver binding model. Use | 345 | Why: Deprecated by the new (standard) device driver binding model. Use |
345 | i2c_driver->probe() and ->remove() instead. | 346 | i2c_driver->probe() and ->remove() instead. |
346 | Who: Jean Delvare <khali@linux-fr.org> | 347 | Who: Jean Delvare <khali@linux-fr.org> |
diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2 index fae3495bcbaf..9698c396b830 100644 --- a/Documentation/i2c/busses/i2c-nforce2 +++ b/Documentation/i2c/busses/i2c-nforce2 | |||
@@ -7,10 +7,14 @@ Supported adapters: | |||
7 | * nForce3 250Gb MCP 10de:00E4 | 7 | * nForce3 250Gb MCP 10de:00E4 |
8 | * nForce4 MCP 10de:0052 | 8 | * nForce4 MCP 10de:0052 |
9 | * nForce4 MCP-04 10de:0034 | 9 | * nForce4 MCP-04 10de:0034 |
10 | * nForce4 MCP51 10de:0264 | 10 | * nForce MCP51 10de:0264 |
11 | * nForce4 MCP55 10de:0368 | 11 | * nForce MCP55 10de:0368 |
12 | * nForce4 MCP61 10de:03EB | 12 | * nForce MCP61 10de:03EB |
13 | * nForce4 MCP65 10de:0446 | 13 | * nForce MCP65 10de:0446 |
14 | * nForce MCP67 10de:0542 | ||
15 | * nForce MCP73 10de:07D8 | ||
16 | * nForce MCP78S 10de:0752 | ||
17 | * nForce MCP79 10de:0AA2 | ||
14 | 18 | ||
15 | Datasheet: not publicly available, but seems to be similar to the | 19 | Datasheet: not publicly available, but seems to be similar to the |
16 | AMD-8111 SMBus 2.0 adapter. | 20 | AMD-8111 SMBus 2.0 adapter. |
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index ef1efa79b1df..f889481762b5 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 | |||
@@ -4,7 +4,7 @@ Supported adapters: | |||
4 | * Intel 82371AB PIIX4 and PIIX4E | 4 | * Intel 82371AB PIIX4 and PIIX4E |
5 | * Intel 82443MX (440MX) | 5 | * Intel 82443MX (440MX) |
6 | Datasheet: Publicly available at the Intel website | 6 | Datasheet: Publicly available at the Intel website |
7 | * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges | 7 | * ServerWorks OSB4, CSB5, CSB6, HT-1000 and HT-1100 southbridges |
8 | Datasheet: Only available via NDA from ServerWorks | 8 | Datasheet: Only available via NDA from ServerWorks |
9 | * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges | 9 | * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges |
10 | Datasheet: Not publicly available | 10 | Datasheet: Not publicly available |
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices new file mode 100644 index 000000000000..b55ce57a84db --- /dev/null +++ b/Documentation/i2c/instantiating-devices | |||
@@ -0,0 +1,167 @@ | |||
1 | How to instantiate I2C devices | ||
2 | ============================== | ||
3 | |||
4 | Unlike PCI or USB devices, I2C devices are not enumerated at the hardware | ||
5 | level. Instead, the software must know which devices are connected on each | ||
6 | I2C bus segment, and what address these devices are using. For this | ||
7 | reason, the kernel code must instantiate I2C devices explicitly. There are | ||
8 | several ways to achieve this, depending on the context and requirements. | ||
9 | |||
10 | |||
11 | Method 1: Declare the I2C devices by bus number | ||
12 | ----------------------------------------------- | ||
13 | |||
14 | This method is appropriate when the I2C bus is a system bus as is the case | ||
15 | for many embedded systems. On such systems, each I2C bus has a number | ||
16 | which is known in advance. It is thus possible to pre-declare the I2C | ||
17 | devices which live on this bus. This is done with an array of struct | ||
18 | i2c_board_info which is registered by calling i2c_register_board_info(). | ||
19 | |||
20 | Example (from omap2 h4): | ||
21 | |||
22 | static struct i2c_board_info __initdata h4_i2c_board_info[] = { | ||
23 | { | ||
24 | I2C_BOARD_INFO("isp1301_omap", 0x2d), | ||
25 | .irq = OMAP_GPIO_IRQ(125), | ||
26 | }, | ||
27 | { /* EEPROM on mainboard */ | ||
28 | I2C_BOARD_INFO("24c01", 0x52), | ||
29 | .platform_data = &m24c01, | ||
30 | }, | ||
31 | { /* EEPROM on cpu card */ | ||
32 | I2C_BOARD_INFO("24c01", 0x57), | ||
33 | .platform_data = &m24c01, | ||
34 | }, | ||
35 | }; | ||
36 | |||
37 | static void __init omap_h4_init(void) | ||
38 | { | ||
39 | (...) | ||
40 | i2c_register_board_info(1, h4_i2c_board_info, | ||
41 | ARRAY_SIZE(h4_i2c_board_info)); | ||
42 | (...) | ||
43 | } | ||
44 | |||
45 | The above code declares 3 devices on I2C bus 1, including their respective | ||
46 | addresses and custom data needed by their drivers. When the I2C bus in | ||
47 | question is registered, the I2C devices will be instantiated automatically | ||
48 | by i2c-core. | ||
49 | |||
50 | The devices will be automatically unbound and destroyed when the I2C bus | ||
51 | they sit on goes away (if ever.) | ||
52 | |||
53 | |||
54 | Method 2: Instantiate the devices explicitly | ||
55 | -------------------------------------------- | ||
56 | |||
57 | This method is appropriate when a larger device uses an I2C bus for | ||
58 | internal communication. A typical case is TV adapters. These can have a | ||
59 | tuner, a video decoder, an audio decoder, etc. usually connected to the | ||
60 | main chip by the means of an I2C bus. You won't know the number of the I2C | ||
61 | bus in advance, so the method 1 described above can't be used. Instead, | ||
62 | you can instantiate your I2C devices explicitly. This is done by filling | ||
63 | a struct i2c_board_info and calling i2c_new_device(). | ||
64 | |||
65 | Example (from the sfe4001 network driver): | ||
66 | |||
67 | static struct i2c_board_info sfe4001_hwmon_info = { | ||
68 | I2C_BOARD_INFO("max6647", 0x4e), | ||
69 | }; | ||
70 | |||
71 | int sfe4001_init(struct efx_nic *efx) | ||
72 | { | ||
73 | (...) | ||
74 | efx->board_info.hwmon_client = | ||
75 | i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info); | ||
76 | |||
77 | (...) | ||
78 | } | ||
79 | |||
80 | The above code instantiates 1 I2C device on the I2C bus which is on the | ||
81 | network adapter in question. | ||
82 | |||
83 | A variant of this is when you don't know for sure if an I2C device is | ||
84 | present or not (for example for an optional feature which is not present | ||
85 | on cheap variants of a board but you have no way to tell them apart), or | ||
86 | it may have different addresses from one board to the next (manufacturer | ||
87 | changing its design without notice). In this case, you can call | ||
88 | i2c_new_probed_device() instead of i2c_new_device(). | ||
89 | |||
90 | Example (from the pnx4008 OHCI driver): | ||
91 | |||
92 | static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END }; | ||
93 | |||
94 | static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev) | ||
95 | { | ||
96 | (...) | ||
97 | struct i2c_adapter *i2c_adap; | ||
98 | struct i2c_board_info i2c_info; | ||
99 | |||
100 | (...) | ||
101 | i2c_adap = i2c_get_adapter(2); | ||
102 | memset(&i2c_info, 0, sizeof(struct i2c_board_info)); | ||
103 | strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE); | ||
104 | isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, | ||
105 | normal_i2c); | ||
106 | i2c_put_adapter(i2c_adap); | ||
107 | (...) | ||
108 | } | ||
109 | |||
110 | The above code instantiates up to 1 I2C device on the I2C bus which is on | ||
111 | the OHCI adapter in question. It first tries at address 0x2c, if nothing | ||
112 | is found there it tries address 0x2d, and if still nothing is found, it | ||
113 | simply gives up. | ||
114 | |||
115 | The driver which instantiated the I2C device is responsible for destroying | ||
116 | it on cleanup. This is done by calling i2c_unregister_device() on the | ||
117 | pointer that was earlier returned by i2c_new_device() or | ||
118 | i2c_new_probed_device(). | ||
119 | |||
120 | |||
121 | Method 3: Probe an I2C bus for certain devices | ||
122 | ---------------------------------------------- | ||
123 | |||
124 | Sometimes you do not have enough information about an I2C device, not even | ||
125 | to call i2c_new_probed_device(). The typical case is hardware monitoring | ||
126 | chips on PC mainboards. There are several dozen models, which can live | ||
127 | at 25 different addresses. Given the huge number of mainboards out there, | ||
128 | it is next to impossible to build an exhaustive list of the hardware | ||
129 | monitoring chips being used. Fortunately, most of these chips have | ||
130 | manufacturer and device ID registers, so they can be identified by | ||
131 | probing. | ||
132 | |||
133 | In that case, I2C devices are neither declared nor instantiated | ||
134 | explicitly. Instead, i2c-core will probe for such devices as soon as their | ||
135 | drivers are loaded, and if any is found, an I2C device will be | ||
136 | instantiated automatically. In order to prevent any misbehavior of this | ||
137 | mechanism, the following restrictions apply: | ||
138 | * The I2C device driver must implement the detect() method, which | ||
139 | identifies a supported device by reading from arbitrary registers. | ||
140 | * Only buses which are likely to have a supported device and agree to be | ||
141 | probed, will be probed. For example this avoids probing for hardware | ||
142 | monitoring chips on a TV adapter. | ||
143 | |||
144 | Example: | ||
145 | See lm90_driver and lm90_detect() in drivers/hwmon/lm90.c | ||
146 | |||
147 | I2C devices instantiated as a result of such a successful probe will be | ||
148 | destroyed automatically when the driver which detected them is removed, | ||
149 | or when the underlying I2C bus is itself destroyed, whichever happens | ||
150 | first. | ||
151 | |||
152 | Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6 | ||
153 | kernels will find out that this method 3 is essentially similar to what | ||
154 | was done there. Two significant differences are: | ||
155 | * Probing is only one way to instantiate I2C devices now, while it was the | ||
156 | only way back then. Where possible, methods 1 and 2 should be preferred. | ||
157 | Method 3 should only be used when there is no other way, as it can have | ||
158 | undesirable side effects. | ||
159 | * I2C buses must now explicitly say which I2C driver classes can probe | ||
160 | them (by the means of the class bitfield), while all I2C buses were | ||
161 | probed by default back then. The default is an empty class which means | ||
162 | that no probing happens. The purpose of the class bitfield is to limit | ||
163 | the aforementioned undesirable side effects. | ||
164 | |||
165 | Once again, method 3 should be avoided wherever possible. Explicit device | ||
166 | instantiation (methods 1 and 2) is much preferred for it is safer and | ||
167 | faster. | ||
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 6b9af7d479c2..c1a06f989cf7 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -207,15 +207,26 @@ You simply have to define a detect callback which will attempt to | |||
207 | identify supported devices (returning 0 for supported ones and -ENODEV | 207 | identify supported devices (returning 0 for supported ones and -ENODEV |
208 | for unsupported ones), a list of addresses to probe, and a device type | 208 | for unsupported ones), a list of addresses to probe, and a device type |
209 | (or class) so that only I2C buses which may have that type of device | 209 | (or class) so that only I2C buses which may have that type of device |
210 | connected (and not otherwise enumerated) will be probed. The i2c | 210 | connected (and not otherwise enumerated) will be probed. For example, |
211 | core will then call you back as needed and will instantiate a device | 211 | a driver for a hardware monitoring chip for which auto-detection is |
212 | for you for every successful detection. | 212 | needed would set its class to I2C_CLASS_HWMON, and only I2C adapters |
213 | with a class including I2C_CLASS_HWMON would be probed by this driver. | ||
214 | Note that the absence of matching classes does not prevent the use of | ||
215 | a device of that type on the given I2C adapter. All it prevents is | ||
216 | auto-detection; explicit instantiation of devices is still possible. | ||
213 | 217 | ||
214 | Note that this mechanism is purely optional and not suitable for all | 218 | Note that this mechanism is purely optional and not suitable for all |
215 | devices. You need some reliable way to identify the supported devices | 219 | devices. You need some reliable way to identify the supported devices |
216 | (typically using device-specific, dedicated identification registers), | 220 | (typically using device-specific, dedicated identification registers), |
217 | otherwise misdetections are likely to occur and things can get wrong | 221 | otherwise misdetections are likely to occur and things can get wrong |
218 | quickly. | 222 | quickly. Keep in mind that the I2C protocol doesn't include any |
223 | standard way to detect the presence of a chip at a given address, let | ||
224 | alone a standard way to identify devices. Even worse is the lack of | ||
225 | semantics associated to bus transfers, which means that the same | ||
226 | transfer can be seen as a read operation by a chip and as a write | ||
227 | operation by another chip. For these reasons, explicit device | ||
228 | instantiation should always be preferred to auto-detection where | ||
229 | possible. | ||
219 | 230 | ||
220 | 231 | ||
221 | Device Deletion | 232 | Device Deletion |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d1b082772e39..be3bde51b564 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -836,6 +836,12 @@ and is between 256 and 4096 characters. It is defined in the file | |||
836 | If specified, z/VM IUCV HVC accepts connections | 836 | If specified, z/VM IUCV HVC accepts connections |
837 | from listed z/VM user IDs only. | 837 | from listed z/VM user IDs only. |
838 | 838 | ||
839 | i2c_bus= [HW] Override the default board specific I2C bus speed | ||
840 | or register an additional I2C bus that is not | ||
841 | registered from board initialization code. | ||
842 | Format: | ||
843 | <bus_id>,<clkrate> | ||
844 | |||
839 | i8042.debug [HW] Toggle i8042 debug mode | 845 | i8042.debug [HW] Toggle i8042 debug mode |
840 | i8042.direct [HW] Put keyboard port into non-translated mode | 846 | i8042.direct [HW] Put keyboard port into non-translated mode |
841 | i8042.dumbkbd [HW] Pretend that controller can only read data from | 847 | i8042.dumbkbd [HW] Pretend that controller can only read data from |
@@ -1325,8 +1331,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1325 | 1331 | ||
1326 | memtest= [KNL,X86] Enable memtest | 1332 | memtest= [KNL,X86] Enable memtest |
1327 | Format: <integer> | 1333 | Format: <integer> |
1328 | range: 0,4 : pattern number | ||
1329 | default : 0 <disable> | 1334 | default : 0 <disable> |
1335 | Specifies the number of memtest passes to be | ||
1336 | performed. Each pass selects another test | ||
1337 | pattern from a given set of patterns. Memtest | ||
1338 | fills the memory with this pattern, validates | ||
1339 | memory contents and reserves bad memory | ||
1340 | regions that are detected. | ||
1330 | 1341 | ||
1331 | meye.*= [HW] Set MotionEye Camera parameters | 1342 | meye.*= [HW] Set MotionEye Camera parameters |
1332 | See Documentation/video4linux/meye.txt. | 1343 | See Documentation/video4linux/meye.txt. |
diff --git a/Documentation/scsi/osd.txt b/Documentation/scsi/osd.txt new file mode 100644 index 000000000000..da162f7fd5f5 --- /dev/null +++ b/Documentation/scsi/osd.txt | |||
@@ -0,0 +1,198 @@ | |||
1 | The OSD Standard | ||
2 | ================ | ||
3 | OSD (Object-Based Storage Device) is a T10 SCSI command set that is designed | ||
4 | to provide efficient operation of input/output logical units that manage the | ||
5 | allocation, placement, and accessing of variable-size data-storage containers, | ||
6 | called objects. Objects are intended to contain operating system and application | ||
7 | constructs. Each object has associated attributes attached to it, which are | ||
8 | integral part of the object and provide metadata about the object. The standard | ||
9 | defines some common obligatory attributes, but user attributes can be added as | ||
10 | needed. | ||
11 | |||
12 | See: http://www.t10.org/ftp/t10/drafts/osd2/ for the latest draft for OSD 2 | ||
13 | or search the web for "OSD SCSI" | ||
14 | |||
15 | OSD in the Linux Kernel | ||
16 | ======================= | ||
17 | osd-initiator: | ||
18 | The main component of OSD in Kernel is the osd-initiator library. Its main | ||
19 | user is intended to be the pNFS-over-objects layout driver, which uses objects | ||
20 | as its back-end data storage. Other clients are the other osd parts listed below. | ||
21 | |||
22 | osd-uld: | ||
23 | This is a SCSI ULD that registers for OSD type devices and provides a testing | ||
24 | platform, both for the in-kernel initiator as well as connected targets. It | ||
25 | currently has no useful user-mode API, though it could have if need be. | ||
26 | |||
27 | exofs: | ||
28 | Is an OSD based Linux file system. It uses the osd-initiator and osd-uld, | ||
29 | to export a usable file system for users. | ||
30 | See Documentation/filesystems/exofs.txt for more details | ||
31 | |||
32 | osd target: | ||
33 | There are no current plans for an OSD target implementation in kernel. For all | ||
34 | needs, a user-mode target that is based on the scsi tgt target framework is | ||
35 | available from Ohio Supercomputer Center (OSC) at: | ||
36 | http://www.open-osd.org/bin/view/Main/OscOsdProject | ||
37 | There are several other target implementations. See http://open-osd.org for more | ||
38 | links. | ||
39 | |||
40 | Files and Folders | ||
41 | ================= | ||
42 | This is the complete list of files included in this work: | ||
43 | include/scsi/ | ||
44 | osd_initiator.h Main API for the initiator library | ||
45 | osd_types.h Common OSD types | ||
46 | osd_sec.h Security Manager API | ||
47 | osd_protocol.h Wire definitions of the OSD standard protocol | ||
48 | osd_attributes.h Wire definitions of OSD attributes | ||
49 | |||
50 | drivers/scsi/osd/ | ||
51 | osd_initiator.c OSD-Initiator library implementation | ||
52 | osd_uld.c The OSD scsi ULD | ||
53 | osd_ktest.{h,c} In-kernel test suite (called by osd_uld) | ||
54 | osd_debug.h Some printk macros | ||
55 | Makefile For both in-tree and out-of-tree compilation | ||
56 | Kconfig Enables inclusion of the different pieces | ||
57 | osd_test.c User-mode application to call the kernel tests | ||
58 | |||
59 | The OSD-Initiator Library | ||
60 | ========================= | ||
61 | osd_initiator is a low level implementation of an osd initiator encoder. | ||
62 | But even though, it should be intuitive and easy to use. Perhaps over time an | ||
63 | higher lever will form that automates some of the more common recipes. | ||
64 | |||
65 | init/fini: | ||
66 | - osd_dev_init() associates a scsi_device with an osd_dev structure | ||
67 | and initializes some global pools. This should be done once per scsi_device | ||
68 | (OSD LUN). The osd_dev structure is needed for calling osd_start_request(). | ||
69 | |||
70 | - osd_dev_fini() cleans up before a osd_dev/scsi_device destruction. | ||
71 | |||
72 | OSD commands encoding, execution, and decoding of results: | ||
73 | |||
74 | struct osd_request's is used to iteratively encode an OSD command and carry | ||
75 | its state throughout execution. Each request goes through these stages: | ||
76 | |||
77 | a. osd_start_request() allocates the request. | ||
78 | |||
79 | b. Any of the osd_req_* methods is used to encode a request of the specified | ||
80 | type. | ||
81 | |||
82 | c. osd_req_add_{get,set}_attr_* may be called to add get/set attributes to the | ||
83 | CDB. "List" or "Page" mode can be used exclusively. The attribute-list API | ||
84 | can be called multiple times on the same request. However, only one | ||
85 | attribute-page can be read, as mandated by the OSD standard. | ||
86 | |||
87 | d. osd_finalize_request() computes offsets into the data-in and data-out buffers | ||
88 | and signs the request using the provided capability key and integrity- | ||
89 | check parameters. | ||
90 | |||
91 | e. osd_execute_request() may be called to execute the request via the block | ||
92 | layer and wait for its completion. The request can be executed | ||
93 | asynchronously by calling the block layer API directly. | ||
94 | |||
95 | f. After execution, osd_req_decode_sense() can be called to decode the request's | ||
96 | sense information. | ||
97 | |||
98 | g. osd_req_decode_get_attr() may be called to retrieve osd_add_get_attr_list() | ||
99 | values. | ||
100 | |||
101 | h. osd_end_request() must be called to deallocate the request and any resource | ||
102 | associated with it. Note that osd_end_request cleans up the request at any | ||
103 | stage and it must always be called after a successful osd_start_request(). | ||
104 | |||
105 | osd_request's structure: | ||
106 | |||
107 | The OSD standard defines a complex structure of IO segments pointed to by | ||
108 | members in the CDB. Up to 3 segments can be deployed in the IN-Buffer and up to | ||
109 | 4 in the OUT-Buffer. The ASCII illustration below depicts a secure-read with | ||
110 | associated get+set of attributes-lists. Other combinations very on the same | ||
111 | basic theme. From no-segments-used up to all-segments-used. | ||
112 | |||
113 | |________OSD-CDB__________| | ||
114 | | | | ||
115 | |read_len (offset=0) -|---------\ | ||
116 | | | | | ||
117 | |get_attrs_list_length | | | ||
118 | |get_attrs_list_offset -|----\ | | ||
119 | | | | | | ||
120 | |retrieved_attrs_alloc_len| | | | ||
121 | |retrieved_attrs_offset -|----|----|-\ | ||
122 | | | | | | | ||
123 | |set_attrs_list_length | | | | | ||
124 | |set_attrs_list_offset -|-\ | | | | ||
125 | | | | | | | | ||
126 | |in_data_integ_offset -|-|--|----|-|-\ | ||
127 | |out_data_integ_offset -|-|--|--\ | | | | ||
128 | \_________________________/ | | | | | | | ||
129 | | | | | | | | ||
130 | |_______OUT-BUFFER________| | | | | | | | ||
131 | | Set attr list |</ | | | | | | ||
132 | | | | | | | | | ||
133 | |-------------------------| | | | | | | ||
134 | | Get attr descriptors |<---/ | | | | | ||
135 | | | | | | | | ||
136 | |-------------------------| | | | | | ||
137 | | Out-data integrity |<------/ | | | | ||
138 | | | | | | | ||
139 | \_________________________/ | | | | ||
140 | | | | | ||
141 | |________IN-BUFFER________| | | | | ||
142 | | In-Data read |<--------/ | | | ||
143 | | | | | | ||
144 | |-------------------------| | | | ||
145 | | Get attr list |<----------/ | | ||
146 | | | | | ||
147 | |-------------------------| | | ||
148 | | In-data integrity |<------------/ | ||
149 | | | | ||
150 | \_________________________/ | ||
151 | |||
152 | A block device request can carry bidirectional payload by means of associating | ||
153 | a bidi_read request with a main write-request. Each in/out request is described | ||
154 | by a chain of BIOs associated with each request. | ||
155 | The CDB is of a SCSI VARLEN CDB format, as described by OSD standard. | ||
156 | The OSD standard also mandates alignment restrictions at start of each segment. | ||
157 | |||
158 | In the code, in struct osd_request, there are two _osd_io_info structures to | ||
159 | describe the IN/OUT buffers above, two BIOs for the data payload and up to five | ||
160 | _osd_req_data_segment structures to hold the different segments allocation and | ||
161 | information. | ||
162 | |||
163 | Important: We have chosen to disregard the assumption that a BIO-chain (and | ||
164 | the resulting sg-list) describes a linear memory buffer. Meaning only first and | ||
165 | last scatter chain can be incomplete and all the middle chains are of PAGE_SIZE. | ||
166 | For us, a scatter-gather-list, as its name implies and as used by the Networking | ||
167 | layer, is to describe a vector of buffers that will be transferred to/from the | ||
168 | wire. It works very well with current iSCSI transport. iSCSI is currently the | ||
169 | only deployed OSD transport. In the future we anticipate SAS and FC attached OSD | ||
170 | devices as well. | ||
171 | |||
172 | The OSD Testing ULD | ||
173 | =================== | ||
174 | TODO: More user-mode control on tests. | ||
175 | |||
176 | Authors, Mailing list | ||
177 | ===================== | ||
178 | Please communicate with us on any deployment of osd, whether using this code | ||
179 | or not. | ||
180 | |||
181 | Any problems, questions, bug reports, lonely OSD nights, please email: | ||
182 | OSD Dev List <osd-dev@open-osd.org> | ||
183 | |||
184 | More up-to-date information can be found on: | ||
185 | http://open-osd.org | ||
186 | |||
187 | Boaz Harrosh <bharrosh@panasas.com> | ||
188 | Benny Halevy <bhalevy@panasas.com> | ||
189 | |||
190 | References | ||
191 | ========== | ||
192 | Weber, R., "SCSI Object-Based Storage Device Commands", | ||
193 | T10/1355-D ANSI/INCITS 400-2004, | ||
194 | http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf | ||
195 | |||
196 | Weber, R., "SCSI Object-Based Storage Device Commands -2 (OSD-2)" | ||
197 | T10/1729-D, Working Draft, rev. 3 | ||
198 | http://www.t10.org/ftp/t10/drafts/osd2/osd2r03.pdf | ||
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 7b4596ac4120..e0203662f9e9 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt | |||
@@ -158,7 +158,7 @@ Offset Proto Name Meaning | |||
158 | 0202/4 2.00+ header Magic signature "HdrS" | 158 | 0202/4 2.00+ header Magic signature "HdrS" |
159 | 0206/2 2.00+ version Boot protocol version supported | 159 | 0206/2 2.00+ version Boot protocol version supported |
160 | 0208/4 2.00+ realmode_swtch Boot loader hook (see below) | 160 | 0208/4 2.00+ realmode_swtch Boot loader hook (see below) |
161 | 020C/2 2.00+ start_sys The load-low segment (0x1000) (obsolete) | 161 | 020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete) |
162 | 020E/2 2.00+ kernel_version Pointer to kernel version string | 162 | 020E/2 2.00+ kernel_version Pointer to kernel version string |
163 | 0210/1 2.00+ type_of_loader Boot loader identifier | 163 | 0210/1 2.00+ type_of_loader Boot loader identifier |
164 | 0211/1 2.00+ loadflags Boot protocol option flags | 164 | 0211/1 2.00+ loadflags Boot protocol option flags |
@@ -170,10 +170,11 @@ Offset Proto Name Meaning | |||
170 | 0224/2 2.01+ heap_end_ptr Free memory after setup end | 170 | 0224/2 2.01+ heap_end_ptr Free memory after setup end |
171 | 0226/2 N/A pad1 Unused | 171 | 0226/2 N/A pad1 Unused |
172 | 0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line | 172 | 0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line |
173 | 022C/4 2.03+ initrd_addr_max Highest legal initrd address | 173 | 022C/4 2.03+ ramdisk_max Highest legal initrd address |
174 | 0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel | 174 | 0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel |
175 | 0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not | 175 | 0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not |
176 | 0235/3 N/A pad2 Unused | 176 | 0235/1 N/A pad2 Unused |
177 | 0236/2 N/A pad3 Unused | ||
177 | 0238/4 2.06+ cmdline_size Maximum size of the kernel command line | 178 | 0238/4 2.06+ cmdline_size Maximum size of the kernel command line |
178 | 023C/4 2.07+ hardware_subarch Hardware subarchitecture | 179 | 023C/4 2.07+ hardware_subarch Hardware subarchitecture |
179 | 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data | 180 | 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data |
@@ -299,14 +300,14 @@ Protocol: 2.00+ | |||
299 | e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version | 300 | e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version |
300 | 10.17. | 301 | 10.17. |
301 | 302 | ||
302 | Field name: readmode_swtch | 303 | Field name: realmode_swtch |
303 | Type: modify (optional) | 304 | Type: modify (optional) |
304 | Offset/size: 0x208/4 | 305 | Offset/size: 0x208/4 |
305 | Protocol: 2.00+ | 306 | Protocol: 2.00+ |
306 | 307 | ||
307 | Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) | 308 | Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) |
308 | 309 | ||
309 | Field name: start_sys | 310 | Field name: start_sys_seg |
310 | Type: read | 311 | Type: read |
311 | Offset/size: 0x20c/2 | 312 | Offset/size: 0x20c/2 |
312 | Protocol: 2.00+ | 313 | Protocol: 2.00+ |
@@ -468,7 +469,7 @@ Protocol: 2.02+ | |||
468 | zero, the kernel will assume that your boot loader does not support | 469 | zero, the kernel will assume that your boot loader does not support |
469 | the 2.02+ protocol. | 470 | the 2.02+ protocol. |
470 | 471 | ||
471 | Field name: initrd_addr_max | 472 | Field name: ramdisk_max |
472 | Type: read | 473 | Type: read |
473 | Offset/size: 0x22c/4 | 474 | Offset/size: 0x22c/4 |
474 | Protocol: 2.03+ | 475 | Protocol: 2.03+ |
@@ -542,7 +543,10 @@ Protocol: 2.08+ | |||
542 | 543 | ||
543 | The payload may be compressed. The format of both the compressed and | 544 | The payload may be compressed. The format of both the compressed and |
544 | uncompressed data should be determined using the standard magic | 545 | uncompressed data should be determined using the standard magic |
545 | numbers. Currently only gzip compressed ELF is used. | 546 | numbers. The currently supported compression formats are gzip |
547 | (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A) and LZMA | ||
548 | (magic number 5D 00). The uncompressed payload is currently always ELF | ||
549 | (magic number 7F 45 4C 46). | ||
546 | 550 | ||
547 | Field name: payload_length | 551 | Field name: payload_length |
548 | Type: read | 552 | Type: read |